RE: [PATCH] (2.4.x bk) efi_memmap_walk_uc

From: Luck, Tony <tony.luck_at_intel.com>
Date: 2003-07-30 08:26:05
> 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.html
Received on Tue Jul 29 18:27:55 2003

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:16 EST