On Tue, Oct 21, 2014 at 12:55:42PM +0200, Peter Zijlstra wrote:
> On Fri, Oct 10, 2014 at 01:56:20PM -0500, Alex Thorlton wrote:
> > On Fri, Oct 10, 2014 at 11:20:52AM +0200, Peter Zijlstra wrote:
> > > So for the numa thing we do everything from the affected tasks context.
> > > There was a lot of
On Fri, Oct 10, 2014 at 11:57:09PM +0200, Vlastimil Babka wrote:
> Hm I haven't seen the code yet, but is perhaps the NUMA scanning working
> similarly enough that a single scanner could handle both the NUMA and THP
> bits to save time?
IIRC the THP thing doesn't need the fault thing, which makes
On Fri, Oct 10, 2014 at 01:56:20PM -0500, Alex Thorlton wrote:
> On Fri, Oct 10, 2014 at 11:20:52AM +0200, Peter Zijlstra wrote:
> > So for the numa thing we do everything from the affected tasks context.
> > There was a lot of arguments early on that that could never really work,
> > but here we a
On Tue, Oct 14, 2014 at 08:38:37PM +0300, Kirill A. Shutemov wrote:
> On Tue, Oct 14, 2014 at 04:54:35PM +0200, Peter Zijlstra wrote:
> > > Is there a reason why we should respect cpuset limitation for kernel
> > > threads?
> >
> > Yes, because we want to allow isolating CPUs from 'random' activit
On Tue, Oct 14, 2014 at 04:54:35PM +0200, Peter Zijlstra wrote:
> > Is there a reason why we should respect cpuset limitation for kernel
> > threads?
>
> Yes, because we want to allow isolating CPUs from 'random' activity.
Okay, it makes sense for cpus_allowed. But we're talking about
mems_allowe
On 10/14/2014 10:54 AM, Peter Zijlstra wrote:
On Tue, Oct 14, 2014 at 02:48:28PM +0300, Kirill A. Shutemov wrote:
Why whould you want to pin khugpeaged? Is there a valid use-case?
Looks like userspace shoots to its leg.
Its just bad design to put so much work in another context. But the
use-c
On Fri, Oct 10, 2014 at 11:57:09PM +0200, Vlastimil Babka wrote:
> On 10.10.2014 20:56, Alex Thorlton wrote:
> >On Fri, Oct 10, 2014 at 11:20:52AM +0200, Peter Zijlstra wrote:
> >>So for the numa thing we do everything from the affected tasks context.
> >>There was a lot of arguments early on that
On Tue, Oct 14, 2014 at 02:48:28PM +0300, Kirill A. Shutemov wrote:
> Why whould you want to pin khugpeaged? Is there a valid use-case?
> Looks like userspace shoots to its leg.
Its just bad design to put so much work in another context. But the
use-case is isolating other cpus.
> Is there a rea
On Wed, Oct 08, 2014 at 02:10:50PM -0500, Alex Thorlton wrote:
> Hey everyone,
>
> I've run into a some frustrating behavior from the khugepaged thread,
> that I'm hoping to get sorted out. It appears that if you pin
> khugepaged to a cpuset (i.e. node 0),
Why whould you want to pin khugpeaged?
On 10.10.2014 20:56, Alex Thorlton wrote:
On Fri, Oct 10, 2014 at 11:20:52AM +0200, Peter Zijlstra wrote:
So for the numa thing we do everything from the affected tasks context.
There was a lot of arguments early on that that could never really work,
but here we are.
Should we convert khugepage
On Fri, Oct 10, 2014 at 11:20:52AM +0200, Peter Zijlstra wrote:
> So for the numa thing we do everything from the affected tasks context.
> There was a lot of arguments early on that that could never really work,
> but here we are.
>
> Should we convert khugepaged to the same? Drive the whole thing
On Wed, Oct 08, 2014 at 02:10:50PM -0500, Alex Thorlton wrote:
> Is this particular bug a known issue?
Its not unexpected for me.
> I've been trying to come up with
> a simple way to fix the bug, but it's a bit difficult since we no longer
> have a way to trace back to the task_struct that we're
Hey everyone,
I've run into a some frustrating behavior from the khugepaged thread,
that I'm hoping to get sorted out. It appears that if you pin
khugepaged to a cpuset (i.e. node 0), and it begins scanning/collapsing
pages for a process on a cpuset that doesn't have any memory nodes in
common wi
13 matches
Mail list logo
