On (10/07/07 11:46), Christoph Lameter didst pronounce:That and they would be available within a specified limit. With grouping pages by mobility, high order pages will be available but it's workload dependant on how many there will be. This sort of predictability is important for hugepages and memory unplug although it's of less relevance to order-3 and order-4 users. I think fsblock as it stands would gain from grouping pages by mobility. It could use high order pages where they were available and fallback to using the slower vmap approach when they weren't. I don't see why highorder page cache and fsblock would be mutually exclusive. For that matter, I don't see why any of these approachs are mutually exclusive with what Andrea is doing other than having more than one way of skinning a cat in the kernal at the same time might be confusing. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -
| Eric Sandeen | Re: [RFC] Heads up on sys_fallocate() |
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 007/196] Chinese: add translation of stable_kernel_rules.txt |
| Andrew Morton | -mm merge plans for 2.6.23 |
git: | |
| David Miller | Re: [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
