Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754526AbaJ1Ply (ORCPT ); Tue, 28 Oct 2014 11:41:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52207 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753968AbaJ1Plw (ORCPT ); Tue, 28 Oct 2014 11:41:52 -0400 Message-ID: <544FB8A8.1090402@redhat.com> Date: Tue, 28 Oct 2014 11:39:20 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Andi Kleen , Alex Thorlton CC: linux-mm@kvack.org, Andrew Morton , Bob Liu , David Rientjes , "Eric W. Biederman" , Hugh Dickins , Ingo Molnar , Kees Cook , "Kirill A. Shutemov" , Mel Gorman , Oleg Nesterov , Peter Zijlstra , Thomas Gleixner , Vladimir Davydov , linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/4] Convert khugepaged to a task_work function References: <1414032567-109765-1-git-send-email-athorlton@sgi.com> <87lho0pf4l.fsf@tassilo.jf.intel.com> <544F9302.4010001@redhat.com> In-Reply-To: <544F9302.4010001@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 changing khugepaged to work as a task_work function >>> instead of a kernel thread. This will give us finer grained control over the >>> page collapse scans, eliminate some unnecessary scans since tasks that are >>> relatively inactive will not be scanned often, and eliminate the unwanted >>> behavior described in the email thread I mentioned. >> >> With your change, what would happen in a single threaded case? >> >> Previously one core would scan and another would run the workload. >> With your change both scanning and running would be on the same >> core. >> >> Would seem like a step backwards to me. > > It's not just scanning, either. > > Memory compaction can spend a lot of time waiting on > locks. Not consuming CPU or anything, but just waiting. > > I am not convinced that moving all that waiting to task > context is a good idea. It may be worth investigating how the hugepage code calls the memory allocation & compaction code. Doing only async compaction from task_work context should probably be ok. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/