lkml.org 
[lkml]   [2002]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.4.19pre1aa1
> They're not in my tree and for very good reasons, Ben did such mistake
> the first time at some point during 2.3. You've a big downside with the
> per-zone information, all normal machines (like with 64M of ram or 2G of
> ram) where theorical O(N) complexity is perfectly fine for lowmem
> dma/normal allocations, will get hurted very much by the per-node lrus.

I'm not sure why it has to be a big impact for the "common desktop"
machine - they should only have one zone anyway. ZONE_DMA should
shrivel up and die in a lonely corner. Yeah, OK, keep it as a
back-compatibility option for those museum pieces that need it,
but personally I'd make ISA DMA support a config option defaulting
to off ... maybe it's possible to do dynamically (just stick no
pages in it, though I suspect it's too late by the time we know).
Hardly any common desktop will need HIGHMEM support, and those
that do will probably get enough kickback from per-zone things to
pay for the cost.

To me, per-node would probably be about as good, but I don't think
per-zone is as bad as you think.

> making it a per-lru spinlock is natural scalability optimization,
> but anyways pagemap_lru_lock isn't a very critical spinlock.

see my other email - it's worse in rmap.

M.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:0.091 / U:3.672 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site