[lkml]   [1998]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 4MB pages and framebuffer access, x11perf results, 2.1.125

On Thu, 29 Oct 1998, MOLNAR Ingo wrote:
> On Wed, 28 Oct 1998, Linus Torvalds wrote:
> > Basically, anything that wants to do "large page" mappings of a frame
> > buffer needs to use something that isn't standard mmap(). Whether that's a
> > special flag to mmap() or something else is immaterial, but it needs to be
> > done on a VMA basis, not on a page table basis. Because we need to
> > disallow partial unmaps etc.
> is something like vma->granularity sufficient? default is 4k, but can be
> 4m (2m) too. (I dont think a single VM_LARGE_PAGE flag is enough, with 3
> level paging we have a theoretical possibility of 4G pages too.) But
> putting this into the vma slows things down unnecessary i fear. Also,
> there is no place for an integer 'granularity' in the mmap interface,
> sigh.

I don't think we want a integer number, we want a "immobility" flag, which
says that any operations on that VMA have to be done on the whole area.
Then it's up to the device driver and the architecture-specific parts to
decide what kind of "immobile" blocks we can have.

For example, some hardware allows special memory regions that aren't
mapped by page tables at all, and don't even have to be powers of two in
size. I don't want the normal Linux memory management to know about them,
but I'd find it acceptable to have a "don't touch me" flag.

I would also suggest that the "don't touch me" flag can _only_ be done for
shared mappings. Because otherwise the VM layer gets very very confused at
fork() time.


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

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