From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: block: Don't count_vm_events for discard bio in submit_bio. Date: Wed, 23 Jun 2010 16:41:19 -0400 Message-ID: <20100623204118.GB31560@redhat.com> References: <1277263491-4068-1-git-send-email-tao.ma@oracle.com> <20100623124046.4dec96d1.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Tao Ma , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jens Axboe , Christoph Hellwig , stable@kernel.org To: Andrew Morton Return-path: Content-Disposition: inline In-Reply-To: <20100623124046.4dec96d1.akpm@linux-foundation.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Jun 23 2010 at 3:40pm -0400, Andrew Morton wrote: > On Wed, 23 Jun 2010 11:24:51 +0800 > Tao Ma wrote: > > > In submit_bio, we count vm events by check READ/WRITE. > > But actually DISCARD_NOBARRIER also has the WRITE flag set. > > It looks as if in blkdev_issue_discard, we also add a > > page as the payload and the bio_has_data check isn't enough. > > So add another check for discard bio. > > > > Cc: Jens Axboe > > Signed-off-by: Tao Ma > > --- > > block/blk-core.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/block/blk-core.c b/block/blk-core.c > > index f84cce4..a725602 100644 > > --- a/block/blk-core.c > > +++ b/block/blk-core.c > > @@ -1586,7 +1586,7 @@ void submit_bio(int rw, struct bio *bio) > > * If it's a regular read/write or a barrier with data attached, > > * go through the normal accounting stuff before submission. > > */ > > - if (bio_has_data(bio)) { > > + if (bio_has_data(bio) && !(rw & BIO_RW_DISCARD)) { > > if (rw & WRITE) { > > count_vm_events(PGPGOUT, count); > > } else { > > Yes, that's a buglet. > > Note that Christoph's "[PATCH, RFC] block: don't allocate a payload for > discard request" will fix it in a better way. Oddly, even with Christoph's patch, bio_has_data() is still true once the discard bio gets to DM. Figuring out why is on my near-term TODO. Mike