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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3258C433FE for ; Wed, 23 Nov 2022 19:07:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239670AbiKWTHM (ORCPT ); Wed, 23 Nov 2022 14:07:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238111AbiKWTHJ (ORCPT ); Wed, 23 Nov 2022 14:07:09 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C71A5BA6A5 for ; Wed, 23 Nov 2022 11:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669230368; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SDRg/5ZBX3XDzjEuh83I6NIeECdfJo03H+sBbmb+sh8=; b=dkryz5SgAswR8+p0ysIVi/dtlTnIDHtP1rgMBl3H+p5vQF6Zvhp08QmTa11skvtJkaqb7v 13sECKH0lz3PuMF15lirWHCCC9ExnvojPP/fD7on0QoAazRpR4Le+LyGnMsGtPU1iODK9e kbeUmiIR7hDd0v2Vp33Ck3qmlCwEh0o= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-166-6s7-BiPVP5G29OaqdhZcgg-1; Wed, 23 Nov 2022 14:06:02 -0500 X-MC-Unique: 6s7-BiPVP5G29OaqdhZcgg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 392181C068CC; Wed, 23 Nov 2022 19:06:02 +0000 (UTC) Received: from [10.22.17.47] (unknown [10.22.17.47]) by smtp.corp.redhat.com (Postfix) with ESMTP id A86FDC15BA5; Wed, 23 Nov 2022 19:06:01 +0000 (UTC) Message-ID: Date: Wed, 23 Nov 2022 14:05:59 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [PATCH] cgroup/cpuset: Optimize update_tasks_nodemask() Content-Language: en-US To: Tejun Heo Cc: "haifeng.xu" , lizefan.x@bytedance.com, hannes@cmpxchg.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org References: <20221123082157.71326-1-haifeng.xu@shopee.com> <5fccf438-fdbe-1bc8-6460-b3911cc51566@redhat.com> From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/23/22 13:54, Tejun Heo wrote: > On Wed, Nov 23, 2022 at 01:48:46PM -0500, Waiman Long wrote: >> I think it is an issue anyway if different threads of a process are in >> different cpusets with different node mask. It is not a configuration that >> should be used at all. > Anything memory related is in the same boat and people still use them > reaching whatever end results they reach. Given the whole thing is pretty > ill-defined, I don't wanna change the behavior now. I am just saying that this is not a good config. I don't have any intention to change the existing behavior at all. > >> This patch makes update_tasks_nodemask() somewhat similar to cpuset_attach() >> where all tasks are iterated to update the node mask but only the task >> leaders are required to update the mm. For a non-group leader task, maybe we >> can check if the group leader is in the same cpuset. If so, we can skip the >> mm update. Do we need similar change in cpuset_attach()? > The leader isn't special tho. We just wanna avoid visiting the same mm more > than once, right? Right, the group leader is just a marker to make it easier to avoid duplicating the work for the same mm. If the group leader happens to be in another cpuset, it will suffer some performance consequence. Cheers, Longman From mboxrd@z Thu Jan 1 00:00:00 1970 From: Waiman Long Subject: Re: [PATCH] cgroup/cpuset: Optimize update_tasks_nodemask() Date: Wed, 23 Nov 2022 14:05:59 -0500 Message-ID: References: <20221123082157.71326-1-haifeng.xu@shopee.com> <5fccf438-fdbe-1bc8-6460-b3911cc51566@redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669230366; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SDRg/5ZBX3XDzjEuh83I6NIeECdfJo03H+sBbmb+sh8=; b=Brta+LkyS9A8u/1n42xRhg9epE0iJtV+LtHV3EmTn6IB6eqH8LOUGBU4zekJZ/1Tw9mZh7 Cko5YvtuSjnvcUZThjDyZwYLzaFdO8Lo8FRHGPBchpc23KZC+mNcdmZhydi4FrJ4gHXakA yl0FyFWEF6Lzchjb/At9XD+4SYG1+pg= Content-Language: en-US In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Tejun Heo Cc: "haifeng.xu" , lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org, hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On 11/23/22 13:54, Tejun Heo wrote: > On Wed, Nov 23, 2022 at 01:48:46PM -0500, Waiman Long wrote: >> I think it is an issue anyway if different threads of a process are in >> different cpusets with different node mask. It is not a configuration that >> should be used at all. > Anything memory related is in the same boat and people still use them > reaching whatever end results they reach. Given the whole thing is pretty > ill-defined, I don't wanna change the behavior now. I am just saying that this is not a good config. I don't have any intention to change the existing behavior at all. > >> This patch makes update_tasks_nodemask() somewhat similar to cpuset_attach() >> where all tasks are iterated to update the node mask but only the task >> leaders are required to update the mm. For a non-group leader task, maybe we >> can check if the group leader is in the same cpuset. If so, we can skip the >> mm update. Do we need similar change in cpuset_attach()? > The leader isn't special tho. We just wanna avoid visiting the same mm more > than once, right? Right, the group leader is just a marker to make it easier to avoid duplicating the work for the same mm. If the group leader happens to be in another cpuset, it will suffer some performance consequence. Cheers, Longman