On Fri, Jul 24, 2015 at 12:49:14PM -0700, David Rientjes wrote:
>
> I don't see the cond_resched() you propose to add, but the need for it is
> obvious with a large user-written nr_hugepages in the above loop.
>
> The suggestion is to check the conditional, reschedule if needed (and if
> so,
On Fri, 2015-07-24 at 10:12 -0700, Jörn Engel wrote:
> On Fri, Jul 24, 2015 at 08:59:59AM +0200, Michal Hocko wrote:
> > On Thu 23-07-15 14:54:31, Spencer Baugh wrote:
> > > From: Joern Engel
> > >
> > > ~150ms scheduler latency for both observed in the wild.
> >
> > This is way to vague. Could
On Thu, 23 Jul 2015, Jörn Engel wrote:
> > The loop is dropping the lock simply to do the allocation and it needs to
> > compare with the user-written number of hugepages to allocate.
>
> And at this point the existing code is racy. Page allocation might
> block for minutes trying to free some
On Fri, Jul 24, 2015 at 08:59:59AM +0200, Michal Hocko wrote:
> On Thu 23-07-15 14:54:31, Spencer Baugh wrote:
> > From: Joern Engel
> >
> > ~150ms scheduler latency for both observed in the wild.
>
> This is way to vague. Could you describe your problem somehow more,
> please?
> There are
On Thu 23-07-15 14:54:31, Spencer Baugh wrote:
> From: Joern Engel
>
> ~150ms scheduler latency for both observed in the wild.
This is way to vague. Could you describe your problem somehow more,
please?
There are schduling points in the page allocator (when it triggers the
reclaim), why are
On Thu 23-07-15 14:54:31, Spencer Baugh wrote:
From: Joern Engel jo...@logfs.org
~150ms scheduler latency for both observed in the wild.
This is way to vague. Could you describe your problem somehow more,
please?
There are schduling points in the page allocator (when it triggers the
reclaim),
On Fri, Jul 24, 2015 at 12:49:14PM -0700, David Rientjes wrote:
I don't see the cond_resched() you propose to add, but the need for it is
obvious with a large user-written nr_hugepages in the above loop.
The suggestion is to check the conditional, reschedule if needed (and if
so, recheck
On Fri, 2015-07-24 at 10:12 -0700, Jörn Engel wrote:
On Fri, Jul 24, 2015 at 08:59:59AM +0200, Michal Hocko wrote:
On Thu 23-07-15 14:54:31, Spencer Baugh wrote:
From: Joern Engel jo...@logfs.org
~150ms scheduler latency for both observed in the wild.
This is way to vague. Could
On Thu, 23 Jul 2015, Jörn Engel wrote:
The loop is dropping the lock simply to do the allocation and it needs to
compare with the user-written number of hugepages to allocate.
And at this point the existing code is racy. Page allocation might
block for minutes trying to free some
On Fri, Jul 24, 2015 at 08:59:59AM +0200, Michal Hocko wrote:
On Thu 23-07-15 14:54:31, Spencer Baugh wrote:
From: Joern Engel jo...@logfs.org
~150ms scheduler latency for both observed in the wild.
This is way to vague. Could you describe your problem somehow more,
please?
There are
On Thu, Jul 23, 2015 at 03:54:43PM -0700, David Rientjes wrote:
> On Thu, 23 Jul 2015, Jörn Engel wrote:
>
> > > This is wrong, you'd want to do any cond_resched() before the page
> > > allocation to avoid racing with an update to h->nr_huge_pages or
> > > h->surplus_huge_pages while
On Thu, 23 Jul 2015, Jörn Engel wrote:
> > This is wrong, you'd want to do any cond_resched() before the page
> > allocation to avoid racing with an update to h->nr_huge_pages or
> > h->surplus_huge_pages while hugetlb_lock was dropped that would result in
> > the page having been uselessly
On Thu, Jul 23, 2015 at 03:08:58PM -0700, David Rientjes wrote:
> On Thu, 23 Jul 2015, Spencer Baugh wrote:
> > From: Joern Engel
> >
> > ~150ms scheduler latency for both observed in the wild.
> >
> > Signed-off-by: Joern Engel
> > Signed-off-by: Spencer Baugh
> > ---
> > mm/hugetlb.c | 2
On Thu, 23 Jul 2015, Spencer Baugh wrote:
> From: Joern Engel
>
> ~150ms scheduler latency for both observed in the wild.
>
> Signed-off-by: Joern Engel
> Signed-off-by: Spencer Baugh
> ---
> mm/hugetlb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/mm/hugetlb.c
From: Joern Engel
~150ms scheduler latency for both observed in the wild.
Signed-off-by: Joern Engel
Signed-off-by: Spencer Baugh
---
mm/hugetlb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index a8c3087..2eb6919 100644
--- a/mm/hugetlb.c
+++
On Thu, 23 Jul 2015, Jörn Engel wrote:
This is wrong, you'd want to do any cond_resched() before the page
allocation to avoid racing with an update to h-nr_huge_pages or
h-surplus_huge_pages while hugetlb_lock was dropped that would result in
the page having been uselessly allocated.
On Thu, Jul 23, 2015 at 03:54:43PM -0700, David Rientjes wrote:
On Thu, 23 Jul 2015, Jörn Engel wrote:
This is wrong, you'd want to do any cond_resched() before the page
allocation to avoid racing with an update to h-nr_huge_pages or
h-surplus_huge_pages while hugetlb_lock was
On Thu, Jul 23, 2015 at 03:08:58PM -0700, David Rientjes wrote:
On Thu, 23 Jul 2015, Spencer Baugh wrote:
From: Joern Engel jo...@logfs.org
~150ms scheduler latency for both observed in the wild.
Signed-off-by: Joern Engel jo...@logfs.org
Signed-off-by: Spencer Baugh
From: Joern Engel jo...@logfs.org
~150ms scheduler latency for both observed in the wild.
Signed-off-by: Joern Engel jo...@logfs.org
Signed-off-by: Spencer Baugh sba...@catern.com
---
mm/hugetlb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index
On Thu, 23 Jul 2015, Spencer Baugh wrote:
From: Joern Engel jo...@logfs.org
~150ms scheduler latency for both observed in the wild.
Signed-off-by: Joern Engel jo...@logfs.org
Signed-off-by: Spencer Baugh sba...@catern.com
---
mm/hugetlb.c | 2 ++
1 file changed, 2 insertions(+)
20 matches
Mail list logo
