mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daeho Jeong <daeho.jeong@samsung.com>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-f2fs-devel@lists.sourceforge.net" 
	<linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix double count on issued discard commands
Date: Tue, 12 Sep 2017 04:34:23 +0000	[thread overview]
Message-ID: <20170912043423epcms1p72de7da42985bf53e94e50ea8474b682c@epcms1p7> (raw)
In-Reply-To: <20170912042916.GA95671@jaegeuk-macbookpro.roam.corp.google.com>

> Yeah, that's exactly like what I made a mistake before.

> I should have mentioned that earlier. :)



Or I think the previous code which used "iter++" might be right.

You might just want to check the fixed number of small discards, DISCARD_ISSUE_RATE,

when issue_cond is "true".



Anyways, I have another question about this function.

How about just issuing, not checking whether it is idle, the fixed number of small

discards, DISCARD_ISSUE_RATE, when issue_cond is "true".

Actually, the discard commands will be issued as "asynchronous" requests,

which has a low priority in the I/O scheduler,

so the performance degradation of other threads by doing this will not be much severe,

but we can make the performance of the storage device better even if there is no idle.



I am just worried about the storage device I/O performance gets worse 

under I/O intensive senario where there is no idle



Thanks,

  parent reply	other threads:[~2017-09-12  4:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-11  3:38 Jaegeuk Kim
2017-09-12  1:53 ` [f2fs-dev] " Chao Yu
2017-09-12  3:53   ` Chao Yu
2017-09-12  4:29     ` Jaegeuk Kim
     [not found]     ` <CGME20170912042935epcas1p4630737028cc7b9536a0c688c92084e84@epcms1p7>
2017-09-12  4:34       ` Daeho Jeong [this message]
2017-09-12 17:11         ` Jaegeuk Kim
2017-09-13  7:13         ` Chao Yu
     [not found]         ` <CGME20170912042935epcas1p4630737028cc7b9536a0c688c92084e84@epcms1p8>
2017-09-13  8:48           ` Daeho Jeong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170912043423epcms1p72de7da42985bf53e94e50ea8474b682c@epcms1p7 \
    --to=daeho.jeong@samsung.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®