From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753931AbeDYWti (ORCPT ); Wed, 25 Apr 2018 18:49:38 -0400 Received: from mail-pg0-f41.google.com ([74.125.83.41]:39317 "EHLO mail-pg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753701AbeDYWtg (ORCPT ); Wed, 25 Apr 2018 18:49:36 -0400 X-Google-Smtp-Source: AB8JxZrJIwmmZjoIpRStKwCEBi4xLuwwY7GqwI92GxO9CCsQICEchm1hykAUIqTq0HTf5KeMFvEHow== Date: Wed, 25 Apr 2018 15:49:34 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Mikulas Patocka cc: James Bottomley , dm-devel@redhat.com, eric.dumazet@gmail.com, mst@redhat.com, netdev@vger.kernel.org, jasowang@redhat.com, Randy Dunlap , linux-kernel@vger.kernel.org, Matthew Wilcox , Michal Hocko , linux-mm@kvack.org, edumazet@google.com, Andrew Morton , virtualization@lists.linux-foundation.org, David Miller , Vlastimil Babka Subject: Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options In-Reply-To: Message-ID: References: <20180421144757.GC14610@bombadil.infradead.org> <20180423151545.GU17484@dhcp22.suse.cz> <20180424170349.GQ17484@dhcp22.suse.cz> <20180424173836.GR17484@dhcp22.suse.cz> <1114eda5-9b1f-4db8-2090-556b4a37c532@infradead.org> <1524694663.4100.21.camel@HansenPartnership.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 25 Apr 2018, Mikulas Patocka wrote: > You need to enable it on boot. Enabling it when the kernel starts to > execute userspace code is already too late (because you would miss > kvmalloc calls in the kernel boot path). > Is your motivation that since kvmalloc() never falls back to vmalloc() on boot because fragmentation is not be an issue at boot that we should catch bugs where it would matter if it had fallen back? If we are worrying about falling back to vmalloc before even initscripts have run I think we have bigger problems.