From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?J=F6rg_R=F6del?= Date: Sun, 21 Jan 2018 07:19:04 +0000 Subject: Re: [PATCH] Intel-IOMMU: Delete an error message for a failed memory allocation in init_dmars() Message-Id: <20180121071903.GD28161@8bytes.org> List-Id: References: <20180120133452.GB28161@8bytes.org> <6b452dfb-b2fc-2417-26b3-bbcdf11ed06f@users.sourceforge.net> <20180120194004.GC28161@8bytes.org> <1516498672.24895.2.camel@perches.com> In-Reply-To: <1516498672.24895.2.camel-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Joe Perches Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, David Woodhouse , SF Markus Elfring , LKML On Sat, Jan 20, 2018 at 05:37:52PM -0800, Joe Perches wrote: > While Markus' commit messages are nearly universally terrible, > is there really any signficant value in knowing when any > particular OOM condition occurs other than the subsystem that > became OOM? > > You're going to be hosed in any case. > > Why isn't the generic OOM stack dump good enough? Because if we know the exact allocation attempt that failed right away, we can more easily check if we can rewrite it so that it is more likely to succeed, e.g. rewriting one higher-order allocation to multiple order-0 allocations. Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?J=F6rg_R=F6del?= Subject: Re: [PATCH] Intel-IOMMU: Delete an error message for a failed memory allocation in init_dmars() Date: Sun, 21 Jan 2018 08:19:04 +0100 Message-ID: <20180121071903.GD28161@8bytes.org> References: <20180120133452.GB28161@8bytes.org> <6b452dfb-b2fc-2417-26b3-bbcdf11ed06f@users.sourceforge.net> <20180120194004.GC28161@8bytes.org> <1516498672.24895.2.camel@perches.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1516498672.24895.2.camel-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Joe Perches Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, David Woodhouse , SF Markus Elfring , LKML List-Id: iommu@lists.linux-foundation.org On Sat, Jan 20, 2018 at 05:37:52PM -0800, Joe Perches wrote: > While Markus' commit messages are nearly universally terrible, > is there really any signficant value in knowing when any > particular OOM condition occurs other than the subsystem that > became OOM? > > You're going to be hosed in any case. > > Why isn't the generic OOM stack dump good enough? Because if we know the exact allocation attempt that failed right away, we can more easily check if we can rewrite it so that it is more likely to succeed, e.g. rewriting one higher-order allocation to multiple order-0 allocations. Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750994AbeAUHTH (ORCPT ); Sun, 21 Jan 2018 02:19:07 -0500 Received: from 8bytes.org ([81.169.241.247]:33576 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750847AbeAUHTF (ORCPT ); Sun, 21 Jan 2018 02:19:05 -0500 Date: Sun, 21 Jan 2018 08:19:04 +0100 From: =?iso-8859-1?Q?J=F6rg_R=F6del?= To: Joe Perches Cc: SF Markus Elfring , iommu@lists.linux-foundation.org, David Woodhouse , LKML , kernel-janitors@vger.kernel.org Subject: Re: [PATCH] Intel-IOMMU: Delete an error message for a failed memory allocation in init_dmars() Message-ID: <20180121071903.GD28161@8bytes.org> References: <20180120133452.GB28161@8bytes.org> <6b452dfb-b2fc-2417-26b3-bbcdf11ed06f@users.sourceforge.net> <20180120194004.GC28161@8bytes.org> <1516498672.24895.2.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1516498672.24895.2.camel@perches.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 20, 2018 at 05:37:52PM -0800, Joe Perches wrote: > While Markus' commit messages are nearly universally terrible, > is there really any signficant value in knowing when any > particular OOM condition occurs other than the subsystem that > became OOM? > > You're going to be hosed in any case. > > Why isn't the generic OOM stack dump good enough? Because if we know the exact allocation attempt that failed right away, we can more easily check if we can rewrite it so that it is more likely to succeed, e.g. rewriting one higher-order allocation to multiple order-0 allocations. Joerg