From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5FF5C433EF for ; Mon, 29 Nov 2021 15:20:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2AF1B6B006C; Mon, 29 Nov 2021 10:20:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 236AB6B0071; Mon, 29 Nov 2021 10:20:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B11F6B0072; Mon, 29 Nov 2021 10:20:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0168.hostedemail.com [216.40.44.168]) by kanga.kvack.org (Postfix) with ESMTP id E9B436B006C for ; Mon, 29 Nov 2021 10:20:05 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id AE5F482F2501 for ; Mon, 29 Nov 2021 15:19:55 +0000 (UTC) X-FDA: 78862327992.14.6D335D9 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf04.hostedemail.com (Postfix) with ESMTP id 39E725002C41 for ; Mon, 29 Nov 2021 15:19:32 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 4417C21709; Mon, 29 Nov 2021 15:19:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1638199176; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZMkuQ8zHorPAG7ibxnbSayAc3aKRfc15yBbo3tHNue4=; b=TD8sHqpIcNmZ7HPIyaJNSUtIW59QZ8Sq9RSyfvFqQ8J3M6VlnJUQ2tJqACOQ68OsbffdTq MFrLl17OP6Gr3R7vbtg9oqVdJ7JcvrhjldqUgNUYcD8FPY1GjXdLti5RD6wUEt/Ow6A3X5 R7V6nPT5pSqtfCcplVyl3di+0VwiYZ8= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 0813CA3B84; Mon, 29 Nov 2021 15:19:35 +0000 (UTC) Date: Mon, 29 Nov 2021 16:19:35 +0100 From: Michal Hocko To: "Aneesh Kumar K.V" Cc: linux-mm@kvack.org, akpm@linux-foundation.org, Ben Widawsky , Dave Hansen , Feng Tang , Andrea Arcangeli , Mel Gorman , Mike Kravetz , Randy Dunlap , Vlastimil Babka , Andi Kleen , Dan Williams , Huang Ying , linux-api@vger.kernel.org Subject: Re: [PATCH v5 2/3] mm/mempolicy: add set_mempolicy_home_node syscall Message-ID: References: <20211116064238.727454-1-aneesh.kumar@linux.ibm.com> <20211116064238.727454-3-aneesh.kumar@linux.ibm.com> <87fsrf1bpu.fsf@linux.ibm.com> <8735nfcbvp.fsf@linux.ibm.com> <87zgpnatza.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zgpnatza.fsf@linux.ibm.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 39E725002C41 X-Stat-Signature: zf495pyesp84c6wncb7iooizyxoghxz9 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=TD8sHqpI; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-HE-Tag: 1638199172-158327 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 29-11-21 20:29:05, Aneesh Kumar K.V wrote: > Michal Hocko writes: > > > On Mon 29-11-21 19:17:06, Aneesh Kumar K.V wrote: > >> Michal Hocko writes: > > [...] > >> > But you do allow to set the home node also for other policies and that > >> > means that a default MPOL_INTERLEAVE would be different from the one > >> > with home_node set up even though they behave exactly the same. > >> > >> I agree that there is no error returned if we try to set the home_node > >> for other memory policies. But there should not be any behaviour > >> differences. We ignore home_node for policies other than BIND and > >> PREFERRED_MANY. > >> > >> The reason I avoided erroring out for other policies was to simplify the > >> error handling. > > > > But this leads to a future extensions problems. How do you tell whether > > a specific policy has a support for home node? > > > >> For example, for a range of addr with a mix of memory > >> policy MPOLD_BIND and MPOL_INTERLEAVE what should be the state after the > >> above system call? > > > > Do we even allow to combinate different memory policies? > > > >> We could say, we ignore setting home_node for vma > >> with policy MPOL_INTERLEAVE and leave the home node set for vma with > >> policy MPOL_BIND. Or should we make the system call return error also > >> undoing the changes done for vmas for which we have set the home_node? > > > > The error behavior is really nasty with the existing behavior. The > > caller has no way to tell which vmas have been updated. The only way is > > to query the state. So if we return an error because of an incompatible > > mempolicy in place we are not much worse than now. If the "error" is > > silent then we establish a dependency on the specific implementation. > > How about > for (; vma && vma->vm_start < end; vma = vma->vm_next) { > > vmstart = max(start, vma->vm_start); > vmend = min(end, vma->vm_end); > new = mpol_dup(vma_policy(vma)); > if (IS_ERR(new)) { > err = PTR_ERR(new); > break; > } > /* > * Only update home node if there is an existing vma policy > */ > if (!new) > continue; > > /* > * If any vma in the range got policy other than MPOL_BIND > * or MPOL_PREFERRED_MANY we return error. We don't reset > * the home node for vmas we already updated before. > */ > if (new->mode != MPOL_BIND && new->mode != MPOL_PREFERRED_MANY) { > err = -EINVAL; > break; > } Maybe ENOSUPP to make the error handling slightly easier. -- Michal Hocko SUSE Labs