On Sun, Sep 08, 2013 at 10:23:55PM +0530, Aneesh Kumar K.V wrote:
> Naoya Horiguchi writes:
>
> > Currently all of page table handling by hugetlbfs code are done under
> > mm->page_table_lock. So when a process have many threads and they heavily
> > access to the memory, lock contention happens
On Sun, Sep 08, 2013 at 10:23:55PM +0530, Aneesh Kumar K.V wrote:
Naoya Horiguchi n-horigu...@ah.jp.nec.com writes:
Currently all of page table handling by hugetlbfs code are done under
mm-page_table_lock. So when a process have many threads and they heavily
access to the memory, lock
Naoya Horiguchi writes:
> Currently all of page table handling by hugetlbfs code are done under
> mm->page_table_lock. So when a process have many threads and they heavily
> access to the memory, lock contention happens and impacts the performance.
>
> This patch makes hugepage support split
Naoya Horiguchi n-horigu...@ah.jp.nec.com writes:
Currently all of page table handling by hugetlbfs code are done under
mm-page_table_lock. So when a process have many threads and they heavily
access to the memory, lock contention happens and impacts the performance.
This patch makes
Currently all of page table handling by hugetlbfs code are done under
mm->page_table_lock. So when a process have many threads and they heavily
access to the memory, lock contention happens and impacts the performance.
This patch makes hugepage support split page table lock so that we use
On Thu, Sep 05, 2013 at 02:48:18PM +0530, Aneesh Kumar K.V wrote:
> Naoya Horiguchi writes:
>
> > Hi Aneesh,
> >
> > On Wed, Sep 04, 2013 at 12:43:19PM +0530, Aneesh Kumar K.V wrote:
> >> Naoya Horiguchi writes:
> >>
> >> > Currently all of page table handling by hugetlbfs code are done under
Naoya Horiguchi writes:
> Hi Aneesh,
>
> On Wed, Sep 04, 2013 at 12:43:19PM +0530, Aneesh Kumar K.V wrote:
>> Naoya Horiguchi writes:
>>
>> > Currently all of page table handling by hugetlbfs code are done under
>> > mm->page_table_lock. So when a process have many threads and they heavily
>>
Naoya Horiguchi n-horigu...@ah.jp.nec.com writes:
Hi Aneesh,
On Wed, Sep 04, 2013 at 12:43:19PM +0530, Aneesh Kumar K.V wrote:
Naoya Horiguchi n-horigu...@ah.jp.nec.com writes:
Currently all of page table handling by hugetlbfs code are done under
mm-page_table_lock. So when a process
On Thu, Sep 05, 2013 at 02:48:18PM +0530, Aneesh Kumar K.V wrote:
Naoya Horiguchi n-horigu...@ah.jp.nec.com writes:
Hi Aneesh,
On Wed, Sep 04, 2013 at 12:43:19PM +0530, Aneesh Kumar K.V wrote:
Naoya Horiguchi n-horigu...@ah.jp.nec.com writes:
Currently all of page table handling
Currently all of page table handling by hugetlbfs code are done under
mm-page_table_lock. So when a process have many threads and they heavily
access to the memory, lock contention happens and impacts the performance.
This patch makes hugepage support split page table lock so that we use
page-ptl
Hi Aneesh,
On Wed, Sep 04, 2013 at 12:43:19PM +0530, Aneesh Kumar K.V wrote:
> Naoya Horiguchi writes:
>
> > Currently all of page table handling by hugetlbfs code are done under
> > mm->page_table_lock. So when a process have many threads and they heavily
> > access to the memory, lock
Naoya Horiguchi writes:
> Currently all of page table handling by hugetlbfs code are done under
> mm->page_table_lock. So when a process have many threads and they heavily
> access to the memory, lock contention happens and impacts the performance.
>
> This patch makes hugepage support split
Naoya Horiguchi n-horigu...@ah.jp.nec.com writes:
Currently all of page table handling by hugetlbfs code are done under
mm-page_table_lock. So when a process have many threads and they heavily
access to the memory, lock contention happens and impacts the performance.
This patch makes
Hi Aneesh,
On Wed, Sep 04, 2013 at 12:43:19PM +0530, Aneesh Kumar K.V wrote:
Naoya Horiguchi n-horigu...@ah.jp.nec.com writes:
Currently all of page table handling by hugetlbfs code are done under
mm-page_table_lock. So when a process have many threads and they heavily
access to the
Currently all of page table handling by hugetlbfs code are done under
mm->page_table_lock. So when a process have many threads and they heavily
access to the memory, lock contention happens and impacts the performance.
This patch makes hugepage support split page table lock so that we use
Currently all of page table handling by hugetlbfs code are done under
mm-page_table_lock. So when a process have many threads and they heavily
access to the memory, lock contention happens and impacts the performance.
This patch makes hugepage support split page table lock so that we use
page-ptl
On Mon 03-06-13 10:34:35, Naoya Horiguchi wrote:
> On Mon, Jun 03, 2013 at 03:19:32PM +0200, Michal Hocko wrote:
> > On Tue 28-05-13 15:52:50, Naoya Horiguchi wrote:
> > > Currently all of page table handling by hugetlbfs code are done under
> > > mm->page_table_lock. This is not optimal because
On Mon, Jun 03, 2013 at 03:19:32PM +0200, Michal Hocko wrote:
> On Tue 28-05-13 15:52:50, Naoya Horiguchi wrote:
> > Currently all of page table handling by hugetlbfs code are done under
> > mm->page_table_lock. This is not optimal because there can be lock
> > contentions between unrelated
On Tue 28-05-13 15:52:50, Naoya Horiguchi wrote:
> Currently all of page table handling by hugetlbfs code are done under
> mm->page_table_lock. This is not optimal because there can be lock
> contentions between unrelated components using this lock.
While I agree with such a change in general I
On Tue 28-05-13 15:52:50, Naoya Horiguchi wrote:
Currently all of page table handling by hugetlbfs code are done under
mm-page_table_lock. This is not optimal because there can be lock
contentions between unrelated components using this lock.
While I agree with such a change in general I am a
On Mon, Jun 03, 2013 at 03:19:32PM +0200, Michal Hocko wrote:
On Tue 28-05-13 15:52:50, Naoya Horiguchi wrote:
Currently all of page table handling by hugetlbfs code are done under
mm-page_table_lock. This is not optimal because there can be lock
contentions between unrelated components
On Mon 03-06-13 10:34:35, Naoya Horiguchi wrote:
On Mon, Jun 03, 2013 at 03:19:32PM +0200, Michal Hocko wrote:
On Tue 28-05-13 15:52:50, Naoya Horiguchi wrote:
Currently all of page table handling by hugetlbfs code are done under
mm-page_table_lock. This is not optimal because there can
Currently all of page table handling by hugetlbfs code are done under
mm->page_table_lock. This is not optimal because there can be lock
contentions between unrelated components using this lock.
This patch makes hugepage support split page table lock so that
we use page->ptl of the leaf node of
Currently all of page table handling by hugetlbfs code are done under
mm-page_table_lock. This is not optimal because there can be lock
contentions between unrelated components using this lock.
This patch makes hugepage support split page table lock so that
we use page-ptl of the leaf node of
24 matches
Mail list logo
