Received: by 10.213.65.68 with SMTP id h4csp3963949imn; Tue, 10 Apr 2018 07:16:34 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/zvQWaG4ZnCxYgNnDlFYCHhYXbrSHLeE3MWcEzlS7ZmlGZwGSvNeHLyHU8pcglD4WYGIu9 X-Received: by 10.101.99.193 with SMTP id n1mr450612pgv.446.1523369794080; Tue, 10 Apr 2018 07:16:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523369794; cv=none; d=google.com; s=arc-20160816; b=LxieHzY8e/NhjHoa7e+u3/bZgNTUGW2GpjpXZH23G9uQpG/T3RSx56yoHyHM2e8GZe NWP9vMfJO8jBklAxA+Ct5skvb45gPxVlp0O7nJRS61jDGOPmEg+fziURqv0CHMYv0kEq A3FKvC5nDxJowrd57JiZl2xm6apcgkOnN3U+estayjCfDAHkwI70gIqrTD0OYi6VnLjc FTf7wYzgMP8YNr26aKcPLhO1WeY+9134XMbTCMKCXdL8GhavuxDSLO6YBG6RF/FZLg9a AUxIMWWu9aQ9Wq7BBF8cgG44YeOS/VOJuURxE2IBMXuF/S1+GMcN3Sq/dgW059S1Rui6 paqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=UXHws0dIthAm620l2H2K8BOWO3p0dpIDpekM+yfw1IY=; b=k5iOs1m5QZQ0dg2+QQG9FlxyHrDKDhge08RFBkl/agjqQQ3K0cytLp6i6N+FiVCPOf s7LhnvFRubKobSRtrxiewOK7XJ9aSgkundRbIJQBJpn69BxsB3TZgEQrLSGVi6bbh5Wa t78MNh/D5LMeY2Nk2R9rumNdCtCsAX1uU70jdCBm4GOUYO7MWrx0DcZjbOsbx+hXXNDc Cw3MeeQu7/XT1OgZD0N2h7LHyp0fNj7mpxAumby+KGPPSU3a309ie2YowWUyJ+PmLIMU Al4bhX6QLbDP/MAiU2wzpAe1IWiV9cUnOr+0dOKZb2zjzYtJTMmaCBaERH9ZonLA/0zP 2U6A== 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 q90si2168210pfa.415.2018.04.10.07.15.56; Tue, 10 Apr 2018 07:16:34 -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 S1754049AbeDJOMM (ORCPT + 99 others); Tue, 10 Apr 2018 10:12:12 -0400 Received: from resqmta-ch2-05v.sys.comcast.net ([69.252.207.37]:60988 "EHLO resqmta-ch2-05v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753145AbeDJOML (ORCPT ); Tue, 10 Apr 2018 10:12:11 -0400 Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id 5txafjuGZFN765u0IfXlsM; Tue, 10 Apr 2018 14:12:10 +0000 Received: from gentwo.org ([98.222.162.64]) by resomta-ch2-09v.sys.comcast.net with SMTP id 5u0GfZlJ0kUWe5u0HfG7aU; Tue, 10 Apr 2018 14:12:10 +0000 Received: by gentwo.org (Postfix, from userid 1001) id C67C91160B41; Tue, 10 Apr 2018 09:12:08 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id C3EF811600FD; Tue, 10 Apr 2018 09:12:08 -0500 (CDT) Date: Tue, 10 Apr 2018 09:12:08 -0500 (CDT) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Vlastimil Babka cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joonsoo Kim , David Rientjes , Pekka Enberg , Tejun Heo , Lai Jiangshan , John Stultz , Thomas Gleixner , Stephen Boyd Subject: Re: [RFC] mm, slab: reschedule cache_reap() on the same CPU In-Reply-To: <20180410081531.18053-1-vbabka@suse.cz> Message-ID: References: <20180410081531.18053-1-vbabka@suse.cz> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfBecCrriSZ6UjdErba0pdGr4zaSMsSrwcfsjIjt6VAB4PFHDZDW1s9yittUW/6VuUbjSx5zGXz8j1+HS+Ycrmx3r7HNAsupsHD1sKO9y8SCpkzH5nLS0 X+9haX+NHX/Ao+70uX9kRnVj2ErulcQzkHIm+7Xksty3d4jd4p62+MzCXh2PSy7IagWLjq+b6qrR74jwMxFMCv5qZ36LCWQ9Y20JaDtNKWZL5kfjRiLaHbN8 3Hs/OdlWyYriXcgRsJM1KYKsS66HSPskvJ8KmwowEcdtA+Bg9hXtnEBRMHucpIud81GF2qxsa/VJqU3ysRwJPHaWw5Up9eyqqi2BRLR+NQirdnUNIeY9xo6b tOQVaGSVFooy93iY5Ycwr4vkBbdl7yyR3WbIpdyDMe55vCDvqJCybNiOsF2aKm9S0A4NGQKtQXH8q8dqPru6589TtlpFdHYrh8DdDUmBHgVnLAO9HkM= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 10 Apr 2018, Vlastimil Babka wrote: > cache_reap() is initially scheduled in start_cpu_timer() via > schedule_delayed_work_on(). But then the next iterations are scheduled via > schedule_delayed_work(), thus using WORK_CPU_UNBOUND. That is a bug.. cache_reap must run on the same cpu since it deals with the per cpu queues of the current cpu. Scheduled_delayed_work() used to guarantee running on teh same cpu. > This patch makes sure schedule_delayed_work_on() is used with the proper cpu > when scheduling the next iteration. The cpu is stored with delayed_work on a > new slab_reap_work_struct super-structure. The current cpu is readily available via smp_processor_id(). Why a super structure? > @@ -4074,7 +4086,8 @@ static void cache_reap(struct work_struct *w) > next_reap_node(); > out: > /* Set up the next iteration */ > - schedule_delayed_work(work, round_jiffies_relative(REAPTIMEOUT_AC)); > + schedule_delayed_work_on(reap_work->cpu, work, > + round_jiffies_relative(REAPTIMEOUT_AC)); schedule_delayed_work_on(smp_processor_id(), work, round_jiffies_relative(REAPTIMEOUT_AC)); instead all of the other changes?