> On Tue, Jul 29, 2003 at 02:34:53PM -0700, Luck, Tony wrote: > > Initially the UC allocator should be really, really basic. Perhaps > > just handing out pages, and without any "free" code to complicate it > > (MCA code should only need to allocate an alternate min_state area > > for each cpu to handle returning to a different context from the one > > that was running when the fault was reported). > > Page granularity would be fine here. I'm not sure anything more > complex would be required any time soon if ever. > > We could like to be able to allocate from or near to a given node in > NUMA configurations. When allocating pages for MINSTATE areas you can > then have that code try to allocate memory on the same node as the > appropriate CPU. We can do that ... but i hope that MCA error recovery isn't a common enough path that allocating min_state from the correct node ever shows up on anyone's performance radar! > How about something like: > > void* ia64_alloc_uc_page(int nodeid); > void ia64_free_us_page(void*); > > as a starting point (for non-NUMA the nodeid won't be interesting of > course). Looks ok. Is the return value from alloc a physical address or a region 6 virtual address? I don't think that I care, so you can pick whatever works best for fetchop (and if I later do care, then it's my own fault for not planning ahead :-) > Ideally freeing memory shouldn't be that hard and for fetchop > certainly would be desirable. We could probably get by with a naive > bitmap allocator per-node or even one of wli's alternative bootmem > allocator suggestions (massaged to suit). Last wli alternative bootmem allocator that I looked at looked like overkill for this (it had all sorts of balanced trees for fast insert and delete). Is fetchop likely to alloc/free a lot (i.e. is performance of alloc/free critical)? A simple list of <base,length> pairs (or maybe <node,base,length> triples??) would work (unless you are expecting hundreds of blocks of uncacheable memory, and a high alloc/free rate. -Tony - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Tue Jul 29 18:27:55 2003
This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:16 EST