From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f48.google.com (mail-qv1-f48.google.com [209.85.219.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E2323BBFB1 for ; Mon, 27 Jul 2026 06:41:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785134483; cv=none; b=PZt0FDMTtTGlZ6tsTQRkxHgOsqLTS74zbl/j2/BgHTXPGXxpBiAQGyOL8VPo2/9FsQYPjttPhN7uUxnHQlTl/J3Z+eGBqTf/1V87M24U8jrsWyugW+TT3Xk/hFP4SfqhYCPKem4+Rr4nGfB8FiOo1/ns99S1kK+nV95GmzlzNOA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785134483; c=relaxed/simple; bh=8W/QrOZaJ2HxV9OWezK2tuHXmTrVCDCFM5shKwy0Dzw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=luQyZvc2Aytmg63VovvfNz2gGwCzTS+euEaGYWMdGPfs/LFIK+5cGyIn24AesjVcHPg8jCJ1iE2SMiLnO0O21osjyEBF/Bjc4ug0bDpRBpvFlsc0Ow7hTWTVaZ5jHWxe7ZCzpFrOfwrE07RXBsaODQ+55mhXzWZYx9SjpNEHeDI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BNwQg7+r; arc=none smtp.client-ip=209.85.219.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BNwQg7+r" Received: by mail-qv1-f48.google.com with SMTP id 6a1803df08f44-8ee88fce572so24100096d6.1 for ; Sun, 26 Jul 2026 23:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785134481; x=1785739281; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=c42QAGjfTeFhG71El6GTZFvQvbIJ6hTV7zn3dWa0CPs=; b=BNwQg7+r5bBgtGusQkktAG/cN/q6atk7QWXrrZlAZH54fwDGyTb7usItfexxTqbDhr 6z/OlFazBbs0QKHPNazNsOfDHYRlxsJoz3GxEri57+N6nxfWdEqw/i+So7CaZun1Jmih W66jnQm34ec5hKMfcv18RQT3x980asC0jJcJEr/5Cg3f5YifHFA4dCdvMBQbHEY2ggYN b8lPRMd26UJOywH8/VeQlmhUoYRqxRqanXQ3vJTrkUcbf/ogjUNTrbnc3NGPE4PVOUus DYkQ0mBTCOXqprxcQ8BrRyi3pqc0CTAxSo2wz6Wh3+OixCWWhxZST6LN5zmQEvi1xFE1 wdvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785134481; x=1785739281; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=c42QAGjfTeFhG71El6GTZFvQvbIJ6hTV7zn3dWa0CPs=; b=bUgX8obeFgQgbg/7m1GlstsWoFFympWRIR0JMwxbi+AqwW4QcTEi4cCz1vxCDL33Ik +dRScj9+0FUBn0tJfJrQo6g5ehlUDxV1Wqs8YnPk7TZ//B8kqsRQoTeWiiBEp14Bj4x6 wvVE8WClq296Ml0gnMELXu03haVrg/gBQ/gkx1Wq4BW6t5yFn0Cv2Y0Hwx5ltUYFPXaE vIPuP88rNwF17MgfYjYwkCNJG8mC9xAtkDUYhr6OLMH1IK8b5FTcsPEsgfii9EruLZ9C Xt8/2NCtzx1nczdKUYjY0TA2ad5zHPbRvK9e/wNPiBP1TBhut72O6D6+A1kAbrsF1koq T0YQ== X-Forwarded-Encrypted: i=1; AHgh+RqoOqnkjjBg6lkj+kyGUIEPApoVrycN5CAEmsb/oRdqycQLdH340lixmtSz0apjYvXD3JKskW0BjAMVU2c=@vger.kernel.org X-Gm-Message-State: AOJu0YxJYv1JsKsdayR+WVCqoNsKGiuaREjMeaapXmihqKZ82YUzrMNc 454+MpA8OzCFIhwMTJIbh0TT6gfz+6q+Bp2mJYRQiqJR5b+6prkhT5VF X-Gm-Gg: AR+sD10fkcr+XALOZ9yjhaMS/kHyN+ETU1VKsPmynABSoy4Jk3FBKne7JjFtm/A5RWG /O5XN8yKLMd1ZCLj125tsidDG+ofcrD1+jByhePjFZrHpc0tkGOVHfndQa+XNA4FEYBy6/ieQdW yn6JDyazkDl+ERaI7xf5Dro6fKuby9r5maD1ErDty+1zxD7xeXMZ5ZGZ6/OyTs+OS94ZJfrgXnU vRJLW0GSk8tn/Ijv3BCTdQAoX90kvT2rdOBML8kl1bdHcQ9DBrEGzAymKyuSdhMuzEzkOuoAWcC rp0u0nLff0hU6LuXvuX6mxrSVWSKz+4+7PDUQ8UPx4mt/ZBLYMWES+dzsCCXzNV+FWm3062bjwE GrMMnzTMmY/peYqfH+KLTwvW/uW1Ez4oI1j5n5Clqgas5BOOtk1jqPBZ8KiuloGUPrRP/7hL7u7 jz5m63D1eL5ME7WyqV0vUIcAIi3G1i X-Received: by 2002:a05:6214:1c84:b0:8ee:e686:1b24 with SMTP id 6a1803df08f44-907ec84fa2dmr82074916d6.45.1785134480960; Sun, 26 Jul 2026 23:41:20 -0700 (PDT) Received: from osman.mioffice.cn ([43.224.245.178]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-907e858195csm58132296d6.21.2026.07.26.23.41.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Jul 2026 23:41:20 -0700 (PDT) From: Zhan Xusheng To: Chen Yu , Peter Zijlstra , Vincent Guittot Cc: K Prateek Nayak , Ingo Molnar , Juri Lelli , Tim Chen , Valentin Schneider , Mel Gorman , Steven Rostedt , Dietmar Eggemann , Ben Segall , Yi Lai , linux-kernel@vger.kernel.org, Zhan Xusheng Subject: Re: [PATCH] sched/cache: Fix a thread aggregation conflict when there is one runnable task Date: Mon, 27 Jul 2026 14:41:11 +0800 Message-ID: <20260727064111.1350672-1-zhanxusheng1024@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260727012914.229171-1-yu.c.chen@intel.com> References: <20260727012914.229171-1-yu.c.chen@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Mon, Jul 27, 2026 at 09:29:14AM +0800, Chen Yu wrote: > - if (sched_asym(env->sd, i, env->dst_cpu) && nr_running == 1) > + if (sched_asym(env->sd, i, env->dst_cpu) && nr_running == 1 && > + env->migration_type != migrate_llc_task) > continue; The fix looks correct for the ITMT case. I also convinced myself it does not introduce a migrate_llc_task <-> asym-packing ping-pong: once the task lands in its preferred LLC, a subsequent asym pull-back is a migrate_task, which goes through can_migrate_task() -> migrate_degrades_llc() -> can_migrate_llc_task() == mig_forbid (moving away from the preferred LLC), so it returns 0 and the task is not pulled back (modulo the nr_balance_failed >= cache_nice_tries + 1 escape). So it should not oscillate. Nice. One minor consistency question: the adjacent single-task filter just above, if (env->sd->flags & SD_ASYM_CPUCAPACITY && !capacity_greater(capacity_of(env->dst_cpu), capacity) && nr_running == 1) continue; has the same nr_running == 1 shape and is not exempted for migrate_llc_task. I don't think it is reachable on current hardware (it would need both multiple LLCs, so migrate_llc_task can fire, and asymmetric CPU capacity at that domain), so this is not a correctness concern for the reported case. But since the two filters now treat migrate_llc_task differently, was leaving the capacity one intentional (capacity prioritized over cache locality on asym-capacity), or just out of scope here? A word in the changelog would make the intent clear. Thanks, Xusheng