Pete Zaitcev wrote:
> This patch is very s/390 specific and breaks all other architectures.
> <<they meant "zSeries specific", surely --zaitcev>>
B.t.w. Martin found a way to make the patch less intrusive so
that it won't break other archs any more ...
>It's a stupid question, but: why can we not simply
>wait until a desired unfragmented memory area is available,
>with a GPF flag? What they describe does not happen in an
>interrupt context, so we can sleep.
Because nobody even *tries* to free adjacent pages to build up
a free order-2 area. You could wait really long ...
This looks hard to fix with the current mm layer. Maybe Rik's
rmap method could help here, because with reverse mappings we
can at least try to free adjacent areas (because we then at least
*know* who's using the pages).
>And another one: why not to increase a kernel-visible or "soft"
>page size to 16KB for zSeries? It's a 64 bits platform. There
>will be some increase in fragmentation, but nobody measured it.
>Perhaps it's not going to be severe. It may even improve paging
>efficiency.
Because then we can mmap() to user space only on 16KB boundaries.
This is a problem in particular for the 31-bit emulation layer,
as 31-bit binaries are laid out on 4KB boundaries by the linker,
so you really need to be able to mmap() on 4KB boundaries.
One way to fix this could be to allow user space mappings on a
different granularity than the 'page size' for the allocator.
(Is this what PAGE_SIZE vs. PAGE_CACHE_SIZE had been intended
for, maybe? It doesn't work at the moment in any case.)
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand Linux for S/390 Design & Development IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen Phone: +49-7031/16-3727 --- Email: Ulrich.Weigand@de.ibm.com- 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/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:54 EST