Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 16 Oct 2020 15:44:57 +0200
From:   Michal Hocko <mhocko@suse.com>
To:     Tianxianting <tian.xianting@h3c.com>
Cc:     "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: vmscan: avoid a unnecessary reschedule in
 shrink_slab()
Message-ID: <20201016134457.GM22589@dhcp22.suse.cz>
References: <20201016033952.1924-1-tian.xianting@h3c.com>
 <20201016120749.GG22589@dhcp22.suse.cz>
 <9a2b772b13f84bdd9517b17d8d72aa89@h3c.com>
 <20201016130208.GI22589@dhcp22.suse.cz>
 <8a25eacf4b37460897911ade338754d3@h3c.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8a25eacf4b37460897911ade338754d3@h3c.com>
Precedence: bulk

On Fri 16-10-20 13:20:41, Tianxianting wrote:
> Thanks
> I understood what you said :)
> But whether it is proper to check reschedule in every loop when lock is taken? 

I do not see any actual problem TBH. cond_resched is mostly to increase
interactivity for non preemptible kernel. It can reduce throughput but
this is a memory reclaim path and I do not expect this to contribute to
any moderate hot paths. Direct reclaim doesn't really count as a hot
path.

-- 
Michal Hocko
SUSE Labs