From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fengguang Wu Subject: Re: [PATCH] writeback: fix writeback cache thrashing Date: Sat, 5 Jan 2013 11:26:42 +0800 Message-ID: <20130105032642.GA8188@localhost> References: <1356847190-7986-1-git-send-email-linkinjeon@gmail.com> <20121231113054.GC7564@quack.suse.cz> <20130102134334.GB30633@quack.suse.cz> <1357261151.5105.2.camel@kernel.cn.ibm.com> <1357346803.5273.10.camel@kernel.cn.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Namjae Jeon , Jan Kara , Wanpeng Li , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Namjae Jeon , Vivek Trivedi , Dave Chinner To: Simon Jeons Return-path: Received: from mga01.intel.com ([192.55.52.88]:60928 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755551Ab3AED0q (ORCPT ); Fri, 4 Jan 2013 22:26:46 -0500 Content-Disposition: inline In-Reply-To: <1357346803.5273.10.camel@kernel.cn.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > > > Hi Namjae, > > > > > > Why use bdi_stat_error here? What's the meaning of its comment "m= aximal > > > error of a stat counter"? > > Hi Simon, > >=20 > > As you know bdi stats (BDI_RECLAIMABLE, BDI_WRITEBACK =E2=80=A6) ar= e kept in > > percpu counters. > > When these percpu counters are incremented/decremented simultaneous= ly > > on multiple CPUs by small amount (individual cpu counter less than > > threshold BDI_STAT_BATCH), > > it is possible that we get approximate value (not exact value) of > > these percpu counters. > > In order, to handle these percpu counter error we have used > > bdi_stat_error. bdi_stat_error is the maximum error which can happe= n > > in percpu bdi stats accounting. > >=20 > > bdi_stat(bdi, BDI_RECLAIMABLE); > > -> This will give approximate value of BDI_RECLAIMABLE by reading > > previous value of percpu count. > >=20 > > bdi_stat_sum(bdi, BDI_RECLAIMABLE); > > ->This will give exact value of BDI_RECLAIMABLE. It will take lock > > and add current percpu count of individual CPUs. > > It is not recommended to use it frequently as it is expensive. W= e > > can better use =E2=80=9Cbdi_stat=E2=80=9D and work with approx valu= e of bdi stats. > >=20 >=20 > Hi Namjae, thanks for your clarify. >=20 > But why compare error stat count to bdi_bground_thresh? What's the It's not comparing bdi_stat_error to bdi_bground_thresh, but rather, in concept, comparing bdi_stat (with error bound adjustments) to bdi_bground_thresh. > relationship between them? I also see bdi_stat_error compare to > bdi_thresh/bdi_dirty in function balance_dirty_pages.=20 Here, it's trying to use bdi_stat_sum(), the accurate (however more costly) version of bdi_stat(), if the error would possibly be large: if (bdi_thresh < 2 * bdi_stat_error(bdi)) { bdi_reclaimable =3D bdi_stat_sum(bdi, BDI_RECLA= IMABLE); //... } else { bdi_reclaimable =3D bdi_stat(bdi, BDI_RECLAIMAB= LE); //... } Here the comment should have explained it well: * In theory 1 page is enough to keep the comsumer-prod= ucer * pipe going: the flusher cleans 1 page =3D> the task = dirties 1 * more page. However bdi_dirty has accounting errors. = So use * the larger and more IO friendly bdi_stat_error. */ if (bdi_dirty <=3D bdi_stat_error(bdi)) break; Thanks, =46engguang -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html