Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754715AbbGXUtU (ORCPT ); Fri, 24 Jul 2015 16:49:20 -0400 Received: from mail-pd0-f169.google.com ([209.85.192.169]:36344 "EHLO mail-pd0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752217AbbGXUtT (ORCPT ); Fri, 24 Jul 2015 16:49:19 -0400 Date: Fri, 24 Jul 2015 13:49:14 -0700 From: =?iso-8859-1?Q?J=F6rn?= Engel To: David Rientjes Cc: Spencer Baugh , Andrew Morton , Naoya Horiguchi , Davidlohr Bueso , Mike Kravetz , Luiz Capitulino , "open list:MEMORY MANAGEMENT" , open list , Spencer Baugh , Joern Engel Subject: Re: [PATCH] hugetlb: cond_resched for set_max_huge_pages and follow_hugetlb_page Message-ID: <20150724204914.GE3458@Sligo.logfs.org> References: <1437688476-3399-1-git-send-email-sbaugh@catern.com> <20150723223651.GH24876@Sligo.logfs.org> <20150723230928.GI24876@Sligo.logfs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2097 Lines: 49 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 the conditional), and then allocate. > > Your third option looks fine and the best place to do the cond_resched(). > I was looking at your second option when I responded and compared it to > the first. We don't want to do cond_resched() immediately before or after > the allocation, the net result is the same: we may be pointlessly > allocating the hugepage and each hugepage allocation can be very > heavyweight. > > So I agree with your third option from the previous email. All right. We are talking about the same thing now. But I previously argued that the pointless allocation will a) not impact correctness and b) be so rare as to not impact performance. The problem with the third option is that it adds a bit of constant overhead all the time to compensate for not doing the pointless allocation. On my systems at least, the pointless allocation will happen, on average, less than once per boot. Unless my systems are vastly unrepresentative, the third option doesn't look appealing to me. > You may also want to include the actual text of the warning from the > kernel log in your commit message. When people encounter this, then will > probably grep in the kernel logs for some keywords to see if it was > already fixed and I fear your current commit message may allow it to be > missed. Ack. I should still have those warning in logfiles somewhere and can hunt them down. J?rn -- Act only according to that maxim whereby you can, at the same time, will that it should become a universal law. -- Immanuel Kant -- 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/