On Fri, Oct 31, 2014 at 09:27:16PM +0100, Vlastimil Babka wrote:
> What could help would be to cache one or few free huge pages per
> zone with cache
> re-fill done asynchronously, e.g. via work queues. The cache could
> benefit fault-THP
> allocations as well. And adding some logic that if nobody
On Mon, Nov 10, 2014 at 11:03:57AM +, Mel Gorman wrote:
> On Tue, Oct 28, 2014 at 08:58:42AM -0400, Rik van Riel wrote:
> > On 10/28/2014 08:12 AM, Andi Kleen wrote:
> > > Alex Thorlton writes:
> > >
> > >> Last week, while discussing possible fixes for some unexpected/unwanted
> > >>
On Mon, Nov 10, 2014 at 11:03:57AM +, Mel Gorman wrote:
On Tue, Oct 28, 2014 at 08:58:42AM -0400, Rik van Riel wrote:
On 10/28/2014 08:12 AM, Andi Kleen wrote:
Alex Thorlton athorl...@sgi.com writes:
Last week, while discussing possible fixes for some unexpected/unwanted
On Fri, Oct 31, 2014 at 09:27:16PM +0100, Vlastimil Babka wrote:
What could help would be to cache one or few free huge pages per
zone with cache
re-fill done asynchronously, e.g. via work queues. The cache could
benefit fault-THP
allocations as well. And adding some logic that if nobody uses
On Tue, Oct 28, 2014 at 08:58:42AM -0400, Rik van Riel wrote:
> On 10/28/2014 08:12 AM, Andi Kleen wrote:
> > Alex Thorlton writes:
> >
> >> Last week, while discussing possible fixes for some unexpected/unwanted
> >> behavior
> >> from khugepaged (see: https://lkml.org/lkml/2014/10/8/515)
On Tue, Oct 28, 2014 at 08:58:42AM -0400, Rik van Riel wrote:
On 10/28/2014 08:12 AM, Andi Kleen wrote:
Alex Thorlton athorl...@sgi.com writes:
Last week, while discussing possible fixes for some unexpected/unwanted
behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515)
On 28.10.2014 16:39, Rik van Riel wrote:
On 10/28/2014 08:58 AM, Rik van Riel wrote:
On 10/28/2014 08:12 AM, Andi Kleen wrote:
Alex Thorlton writes:
Last week, while discussing possible fixes for some
unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515)
On 28.10.2014 16:39, Rik van Riel wrote:
On 10/28/2014 08:58 AM, Rik van Riel wrote:
On 10/28/2014 08:12 AM, Andi Kleen wrote:
Alex Thorlton athorl...@sgi.com writes:
Last week, while discussing possible fixes for some
unexpected/unwanted behavior
from khugepaged (see:
On Thu, Oct 30, 2014 at 09:35:44AM +0100, Andi Kleen wrote:
> We already have too many VM tunables. Better would be to switch
> automatically somehow.
>
> I guess you could use some kind of work stealing scheduler, but these
> are fairly complicated. Maybe some simpler heuristics can be found.
>
> I suppose from the single-threaded point of view, it could be. Maybe we
It's not only for single threaded. Consider the "has to wait a long time
for a lock" problem Rik pointed out. With that multiple threads are
always better.
> could look at this a bit differently. What if we allow
I suppose from the single-threaded point of view, it could be. Maybe we
It's not only for single threaded. Consider the has to wait a long time
for a lock problem Rik pointed out. With that multiple threads are
always better.
could look at this a bit differently. What if we allow processes
On Thu, Oct 30, 2014 at 09:35:44AM +0100, Andi Kleen wrote:
We already have too many VM tunables. Better would be to switch
automatically somehow.
I guess you could use some kind of work stealing scheduler, but these
are fairly complicated. Maybe some simpler heuristics can be found.
That
On Wed, Oct 29, 2014 at 04:58:39PM -0500, Alex Thorlton wrote:
> On Tue, Oct 28, 2014 at 05:12:26AM -0700, Andi Kleen wrote:
> > Alex Thorlton writes:
> >
> > > Last week, while discussing possible fixes for some unexpected/unwanted
> > > behavior
> > > from khugepaged (see:
On Tue, Oct 28, 2014 at 05:12:26AM -0700, Andi Kleen wrote:
> Alex Thorlton writes:
>
> > Last week, while discussing possible fixes for some unexpected/unwanted
> > behavior
> > from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
> > mentioned possibly changing changing
On Tue, Oct 28, 2014 at 05:12:26AM -0700, Andi Kleen wrote:
Alex Thorlton athorl...@sgi.com writes:
Last week, while discussing possible fixes for some unexpected/unwanted
behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing
On Wed, Oct 29, 2014 at 04:58:39PM -0500, Alex Thorlton wrote:
On Tue, Oct 28, 2014 at 05:12:26AM -0700, Andi Kleen wrote:
Alex Thorlton athorl...@sgi.com writes:
Last week, while discussing possible fixes for some unexpected/unwanted
behavior
from khugepaged (see:
On 10/28/2014 08:58 AM, Rik van Riel wrote:
On 10/28/2014 08:12 AM, Andi Kleen wrote:
Alex Thorlton writes:
Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing
On 10/28/2014 08:12 AM, Andi Kleen wrote:
> Alex Thorlton writes:
>
>> Last week, while discussing possible fixes for some unexpected/unwanted
>> behavior
>> from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
>> mentioned possibly changing changing khugepaged to work as a
Alex Thorlton writes:
> Last week, while discussing possible fixes for some unexpected/unwanted
> behavior
> from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
> mentioned possibly changing changing khugepaged to work as a task_work
> function
> instead of a kernel
Alex Thorlton athorl...@sgi.com writes:
Last week, while discussing possible fixes for some unexpected/unwanted
behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing changing khugepaged to work as a task_work
function
instead of a
On 10/28/2014 08:12 AM, Andi Kleen wrote:
Alex Thorlton athorl...@sgi.com writes:
Last week, while discussing possible fixes for some unexpected/unwanted
behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing changing khugepaged to
On 10/28/2014 08:58 AM, Rik van Riel wrote:
On 10/28/2014 08:12 AM, Andi Kleen wrote:
Alex Thorlton athorl...@sgi.com writes:
Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned
On Thu, Oct 23, 2014 at 01:05:19PM -0500, Alex Thorlton wrote:
> I'll double check everything and do a resend here shortly.
Resend is out there. It looks like I got this one right (maybe next
time I'll get it on the first try :). Thanks for pointing out my error,
Rik!
- Alex
--
To unsubscribe
Hey everyone,
Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing changing khugepaged to work as a task_work function
instead of a kernel thread. This will give us
On Thu, Oct 23, 2014 at 01:55:13PM -0400, Rik van Riel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/22/2014 10:49 PM, Alex Thorlton wrote:
>
> > Alex Thorlton (4): Disable khugepaged thread Add pgcollapse
> > controls to task_struct Convert khugepaged scan functions to work
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/22/2014 10:49 PM, Alex Thorlton wrote:
> Alex Thorlton (4): Disable khugepaged thread Add pgcollapse
> controls to task_struct Convert khugepaged scan functions to work
> with task_work Add /proc files to expose per-mm pgcollapse stats
Is it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/22/2014 10:49 PM, Alex Thorlton wrote:
Alex Thorlton (4): Disable khugepaged thread Add pgcollapse
controls to task_struct Convert khugepaged scan functions to work
with task_work Add /proc files to expose per-mm pgcollapse stats
Is it just
On Thu, Oct 23, 2014 at 01:55:13PM -0400, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/22/2014 10:49 PM, Alex Thorlton wrote:
Alex Thorlton (4): Disable khugepaged thread Add pgcollapse
controls to task_struct Convert khugepaged scan functions to work
with
Hey everyone,
Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing changing khugepaged to work as a task_work function
instead of a kernel thread. This will give us
On Thu, Oct 23, 2014 at 01:05:19PM -0500, Alex Thorlton wrote:
I'll double check everything and do a resend here shortly.
Resend is out there. It looks like I got this one right (maybe next
time I'll get it on the first try :). Thanks for pointing out my error,
Rik!
- Alex
--
To unsubscribe
Hey everyone,
Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing changing khugepaged to work as a task_work function
instead of a kernel thread. This will give us
Please ignore! Screwed up my git send-email... Sending the proper
version here in a bit...
On Wed, Oct 22, 2014 at 09:35:02PM -0500, Alex Thorlton wrote:
> Hey everyone,
>
> Last week, while discussing possible fixes for some unexpected/unwanted
> behavior
> from khugepaged (see:
Hey everyone,
Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing changing khugepaged to work as a task_work function
instead of a kernel thread. This will give us
Hey everyone,
Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing changing khugepaged to work as a task_work function
instead of a kernel thread. This will give us
Please ignore! Screwed up my git send-email... Sending the proper
version here in a bit...
On Wed, Oct 22, 2014 at 09:35:02PM -0500, Alex Thorlton wrote:
Hey everyone,
Last week, while discussing possible fixes for some unexpected/unwanted
behavior
from khugepaged (see:
Hey everyone,
Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing changing khugepaged to work as a task_work function
instead of a kernel thread. This will give us
36 matches
Mail list logo
