Messages in this thread | | | Date | Wed, 10 Nov 2004 18:26:59 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] VM routine fixes |
| |
David Woodhouse <dwmw2@infradead.org> wrote: > > On Wed, 2004-11-10 at 11:01 -0800, Andrew Morton wrote: > > Why _does_ !CONFIG_MMU futz around with page counts in such weird ways > > anyway? Why does it have requirements for higher-order pages which differ > > from !CONFIG_MMU? > > Because in the absence of an MMU, an mmap of a large region (like an > executable) has to be satisfied by a large enough allocation followed by > a read.
That's currently implemented via this:
/* * We need to reference all the pages for this order, otherwise if * anyone accesses one of the pages with (get/put) it will be freed. */ for (i = 0; i < (1 << order); i++) set_page_count(page+i, 1);
I assume the CONFIG_MMU logic assumes that it's legal to physically free a single page from inside the middle of a higher-order page. I wonder if the no-buddy-bitmap patches allow that? And if they've been tested with that?
See, if we enable the compound page logic if !CONFIG_MMU then all this stuff just goes away and the page refcounting is controlled purely by the head page. A get_page() or a put_page() against any of the constituent pages will manipulate the head page's refcount.
> > If someone could explain the reasoning behind the current code, and the FRV > > enhancements then perhaps we could work something out. > > I think these parts aren't FRV-specific; they're the fixes required to > do proper shared readable mmap with !CONFIG_MMU. That was a prerequisite > for the ELF-FDPIC executable format, which allows real shared libraries > on uClinux. >
OK. - 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/
| |