David Gibson wrote on Wednesday, March 08, 2006 2:23 AM
> Yes. This is a simplifying assumption. I know of no real application
> that will waste pages because of this behaviour. If you know one,
> maybe we will need to reconsider.
>
> > I have an idea. How about to record all the start/end address of
> > huge page mmaping of the inode? Long long ago, there was a patch at
> > http://marc.theaimsgroup.com/?l=lse-tech&m=108187931924134&w=2.
> > Of course, we need port it to the latest kernel if this idea is better.
>
> I know the patch - I was going to port it to the current kernel, but
> came up with my patch instead, because it seemed like a simpler
> approach.
I really think the Variable length reservation system is the way to go
for tracking hugetlb commit. It is more robust and in my opinion, it
is better than traverse the page cache radix tree. At least, you don't
have to worry about all the race condition there. Oh, it also can get
rid of the hugetlb_instantiation_mutex that was introduced. Someday,
people is going to scream at you for serializing hugetlb fault path.
- Ken
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
