On Fri, 2007-08-03 at 09:53 -0700, Nish Aravamudan wrote:
> On 8/3/07, Adam Litke <[EMAIL PROTECTED]> wrote:
> > On Mon, 2007-07-30 at 15:15 +0800, Zhang, Yanmin wrote:
> > > On Fri, 2007-07-27 at 11:37 -0500, Adam Litke wrote:
> > > > Hey... I am amazed at how quickly you came back with a patch fo
On 8/3/07, Adam Litke <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-07-30 at 15:15 +0800, Zhang, Yanmin wrote:
> > On Fri, 2007-07-27 at 11:37 -0500, Adam Litke wrote:
> > > Hey... I am amazed at how quickly you came back with a patch for this :)
> > > Thanks for looking at it. Unfortunately there is
On Mon, 2007-07-30 at 15:15 +0800, Zhang, Yanmin wrote:
> On Fri, 2007-07-27 at 11:37 -0500, Adam Litke wrote:
> > Hey... I am amazed at how quickly you came back with a patch for this :)
> > Thanks for looking at it. Unfortunately there is one show-stopper and I
> > have some reservations (pun de
On Fri, 2007-07-27 at 11:37 -0500, Adam Litke wrote:
> Hey... I am amazed at how quickly you came back with a patch for this :)
> Thanks for looking at it. Unfortunately there is one show-stopper and I
> have some reservations (pun definitely intended) with your approach:
Thanks for your great com
Hey... I am amazed at how quickly you came back with a patch for this :)
Thanks for looking at it. Unfortunately there is one show-stopper and I
have some reservations (pun definitely intended) with your approach:
First, your patch does not pass the libhugetlbfs test
'alloc-instantiate-race' whic
hugetlb_instantiation_mutex is a big lock in function hugetlb_fault. It
serializes
all hugetlb page faults, no matter if the faults happen in the same address
space,
and no matter if the faults are related to the same inode.
Why is there such a big lock? Huge pages are limited resources. When th
6 matches
Mail list logo
