Received: by 10.213.65.68 with SMTP id h4csp782945imn; Wed, 4 Apr 2018 07:12:29 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+YFfPy0hOs3wsZdp5t8l18of6heYpcw1AYh/E8bf76BfJ4XmwX6yFDK+qnnuUnpK9U8yab X-Received: by 2002:a17:902:28e4:: with SMTP id f91-v6mr19246548plb.336.1522851149365; Wed, 04 Apr 2018 07:12:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522851149; cv=none; d=google.com; s=arc-20160816; b=BjmvNsVDBGHPBmnQFFKI8uey1PUIMLLdPnypHRP3K7m9taw08REswNUIhg8kQxnfBP vvMxlJ1fmiq4N/pwUY3W6yp0/x9ymzDUDDlsJ2TI8M3tZrUMWelajg5ictWV/2BRwD6X VXAT+gD0wtonMSlc9yDxFOxhzdvwttcQkr2NX5XB4dLRlwl4fYv0wuAWqtC1ee9O9pty WsA+BjksbHQMC86GpU0h2R5j0Oxf/q0dQmnai3+fIqiif8sKqFt/s04eB+9m78RW1ZXM weqbCMzv6YdcLWXNxSmGY3X9zz8tbe+vxE0ZvtWPwHW1s/qjgbdC8SChOMPJu6kHAUgU C7fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=DK4GmBbhsRRqnsR3klZVcnnJEgZFhKHH1rgRP3T3Om4=; b=QZ5OWJHxgnj4XJvNTCi9byk2mP1s+/AWyFHI0SXqVBzAboQF0lJDe8w9D1MYJ02I7K Axzc8Av60BxhAz6csJTDK7yTAgX7qcM5OwY6GGJzLgpcH9osYmMWSDUea76w/9w7ENRX wRQbDz1u+zust9dVBqm14HK7OJo4tSgvG6zcKicB1Ly1rK6z4xzPGEB7UyvkxQPCYa0s ZGHkVr3PRPq8MkRjqie/M7hXMlQ4r1y/B2hbiq7BJZNdhgWzNhLdLtwW501a3rLJlzFw Z4oVYt7mc9t7BXLtlMMu+2mk9OuWH/0aRt53olou+P+HRSPUNRjvuuX5ueHGfS6O7eM+ mpFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q4-v6si382877plr.712.2018.04.04.07.12.14; Wed, 04 Apr 2018 07:12:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751365AbeDDOK5 (ORCPT + 99 others); Wed, 4 Apr 2018 10:10:57 -0400 Received: from mx2.suse.de ([195.135.220.15]:57273 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751213AbeDDOK4 (ORCPT ); Wed, 4 Apr 2018 10:10:56 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 62964AF96; Wed, 4 Apr 2018 14:10:55 +0000 (UTC) Date: Wed, 4 Apr 2018 16:10:52 +0200 From: Michal Hocko To: Steven Rostedt Cc: Zhaoyang Huang , Ingo Molnar , linux-kernel@vger.kernel.org, kernel-patch-test@lists.linaro.org, Andrew Morton , Joel Fernandes , linux-mm@kvack.org, Vlastimil Babka Subject: Re: [PATCH v1] kernel/trace:check the val against the available mem Message-ID: <20180404141052.GH6312@dhcp22.suse.cz> References: <20180403121614.GV5501@dhcp22.suse.cz> <20180403082348.28cd3c1c@gandalf.local.home> <20180403123514.GX5501@dhcp22.suse.cz> <20180403093245.43e7e77c@gandalf.local.home> <20180403135607.GC5501@dhcp22.suse.cz> <20180403101753.3391a639@gandalf.local.home> <20180403161119.GE5501@dhcp22.suse.cz> <20180403185627.6bf9ea9b@gandalf.local.home> <20180404062039.GC6312@dhcp22.suse.cz> <20180404085901.5b54fe32@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180404085901.5b54fe32@gandalf.local.home> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 04-04-18 08:59:01, Steven Rostedt wrote: [...] > + /* > + * Check if the available memory is there first. > + * Note, si_mem_available() only gives us a rough estimate of available > + * memory. It may not be accurate. But we don't care, we just want > + * to prevent doing any allocation when it is obvious that it is > + * not going to succeed. > + */ > + i = si_mem_available(); > + if (i < nr_pages) > + return -ENOMEM; > + > > Better? I must be really missing something here. How can that work at all for e.g. the zone_{highmem/movable}. You will get false on the above tests even when you will have hard time to allocate anything from your destination zones. -- Michal Hocko SUSE Labs