Messages in this thread | | | Date | Thu, 24 Jun 2004 11:29:17 -0700 | From | William Lee Irwin III <> | Subject | Re: [discuss] Re: 32-bit dma allocations on 64-bit platforms |
| |
On Thu, Jun 24, 2004 at 08:07:56PM +0200, Andrea Arcangeli wrote: > how do you handle swapoff and mlock then? anonymous memory is pinned w/o > swap. You've relocate the stuff during the mlock or swapoff to obey to > the pin limits to make this work right, and it sounds quite complicated > and it would hurt mlock performance a lot too (some big app uses mlock > to pagein w/o page faults tons of stuff).
I don't have a predetermined answer to this. I can take suggestions (e.g. page migration) for a preferred implementation of how pinned userspace is to be handled, or refrain from discriminating between pinned and unpinned allocations as desired. Another possibility would be ignoring the mlocked status of userspace pages in situations where cross-zone migration would be considered necessary.
On Thu, Jun 24, 2004 at 08:07:56PM +0200, Andrea Arcangeli wrote: > Note that the "pinned" thing in theory makes *perfect* sense, but it > only makes sense on _top_ of lowmem_zone_reserve_ratio, it's not an > alternative. > When the page is pinned you obey to the "lowmem_zone_reserve_ratio" when > it's _not_ pinned then you absolutely ignore the > lowmem_zone_reseve_ratio and you go with the watermarks[curr_zone_idx] > instead of the class_idx. > But in practice I doubt it worth it since I doubt you want to relocate > pagecache and anonymous memory during swapoff/mlock.
I suspect that if it's worth it to migrate userspace memory between zones, it's only worthwhile to do so during page reclamation. The first idea that occurs to me is checking for how plentiful memory in upper zones is when a pinned userspace page in a lower zone is found on the LRU, and then migrating it as an alternative to outright eviction or ignoring its pinned status.
I didn't actually think of it as an alternative, but as just feeding your algorithm the more precise information the comment implied it wanted. I'm basically just looking to get things as solid as possible, so I'm not wedded to a particular solution. If it's too unclear how to handle the situation when pinned allocations can be distinguished, I can just port the 2.4 fallback discouraging algorithm without extensions.
-- wli - 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/
| |