[lkml]   [2004]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] VM routine fixes
David Woodhouse <> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.047 / U:7.492 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site