![]() | |||||||||||||
Messages in this thread |
On Mon, Mar 15, 2004 at 05:41:54PM -0500, Rik van Riel wrote: > On Mon, 15 Mar 2004, Andrea Arcangeli wrote: > > > As I told Andrew, you've also to make sure not to start always from the > > highmemzone, and from the code this seems not the case, so my 2G > > scenario still applies. > > Agreed, the scenario applies. However, I don't see how a > global LRU would fix it in eg. the case of an AMD64 NUMA > system... I think I mentioned the per-node lru would be enough for numa, I'm only talking here about per-zone lru, per-node numa needs are another matter. For 64bit per-node or per-zone is basically the same in practice. however after 2.6.4 will be fixed even the per-zone should not generate loss of caching info, so with that part fixed I'm not against per-zone even if it's more difficult to be fair. > And once we fix it right for those NUMA systems, we can > use the same code to take care of balancing between zones > on normal PCs, giving us the scalability benefits of the > per-zone lists and locks. I argue those scalability benefits of the locks, on a 32G machine or on a 1G machine those locks benefits are near zero. The only significant benefit is in terms of computational complexity of the normal-zone allocations, where we'll only walk on the zone-normal and zone-dma pages. > How about AMD64 NUMA systems ? > What evens out the LRU pressure there in 2.4 ? by the time you say 64bit you can forget the per-zone per-node differences. sure there will be still a difference but it's cosmetical so I don't care about those per-zone lru issues for 64bit hardware, infact on 64bit hardware per-zone (even if totally unfair) is the most optimal just in case somebody asks for ZONE_DMA more than once per day. But the difference is so small in practice that even global would be ok. the per-node on numa (not necessairly on amd64, infact in amd64 the penality is so small that I doubt things like that will payoff big) still remains but that's not the thing I was discussing here. - 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:01 [from the cache] ©2003-2008 | |||||||||||||