From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751739AbdITPSz (ORCPT ); Wed, 20 Sep 2017 11:18:55 -0400 Received: from mail-io0-f176.google.com ([209.85.223.176]:51287 "EHLO mail-io0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751593AbdITPSv (ORCPT ); Wed, 20 Sep 2017 11:18:51 -0400 X-Google-Smtp-Source: AOwi7QBx7ngdxg4T8r1wmmnZRti9jkc7AYM4cQLY4bt4fNHk4JkdA0gZSuQUkNMTxP0bwDrqpwzfzg== Subject: Re: [PATCH 1/6] buffer: cleanup free_more_memory() flusher wakeup To: Jan Kara Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, hannes@cmpxchg.org, clm@fb.com References: <1505850787-18311-1-git-send-email-axboe@kernel.dk> <1505850787-18311-2-git-send-email-axboe@kernel.dk> <20170920141727.GB11106@quack2.suse.cz> From: Jens Axboe Message-ID: Date: Wed, 20 Sep 2017 09:18:47 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170920141727.GB11106@quack2.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/20/2017 08:17 AM, Jan Kara wrote: > On Tue 19-09-17 13:53:02, Jens Axboe wrote: >> This whole function is... interesting. Change the wakeup call >> to the flusher threads to pass in nr_pages == 0, instead of >> some random number of pages. This matches more closely what >> similar cases do for memory shortage/reclaim. >> >> Signed-off-by: Jens Axboe > > Ok, probably makes sense. You can add: > > Reviewed-by: Jan Kara > > BTW, after this nobody seems to use the number of pages for > wakeup_flusher_threads() so can you just delete the argument for the > function? After all system-wide wakeup is useful only for system wide > sync(2) or memory reclaim so number of pages isn't very useful... Great observation! That's true, and if we kill that, it enables further cleanups down the line for patch 5 and 6. I have incorporated that. -- Jens Axboe From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [PATCH 1/6] buffer: cleanup free_more_memory() flusher wakeup To: Jan Kara Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, hannes@cmpxchg.org, clm@fb.com References: <1505850787-18311-1-git-send-email-axboe@kernel.dk> <1505850787-18311-2-git-send-email-axboe@kernel.dk> <20170920141727.GB11106@quack2.suse.cz> From: Jens Axboe Message-ID: Date: Wed, 20 Sep 2017 09:18:47 -0600 MIME-Version: 1.0 In-Reply-To: <20170920141727.GB11106@quack2.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: On 09/20/2017 08:17 AM, Jan Kara wrote: > On Tue 19-09-17 13:53:02, Jens Axboe wrote: >> This whole function is... interesting. Change the wakeup call >> to the flusher threads to pass in nr_pages == 0, instead of >> some random number of pages. This matches more closely what >> similar cases do for memory shortage/reclaim. >> >> Signed-off-by: Jens Axboe > > Ok, probably makes sense. You can add: > > Reviewed-by: Jan Kara > > BTW, after this nobody seems to use the number of pages for > wakeup_flusher_threads() so can you just delete the argument for the > function? After all system-wide wakeup is useful only for system wide > sync(2) or memory reclaim so number of pages isn't very useful... Great observation! That's true, and if we kill that, it enables further cleanups down the line for patch 5 and 6. I have incorporated that. -- Jens Axboe -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org