From: Hugh Dickins <hughd@google.com>
To: Shaohua Li <shli@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Holger Kiehl <Holger.Kiehl@dwd.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Jason Mattax <jmattax@storytotell.org>,
linux-mm@kvack.org
Subject: Re: [RFC]swap: don't do discard if no discard option added
Date: Fri, 23 Mar 2012 04:00:23 -0700 (PDT) [thread overview]
Message-ID: <alpine.LSU.2.00.1203230338110.31703@eggly.anvils> (raw)
In-Reply-To: <CANejiEUyPSNQ7q85ZDz-B3iHikHLgZLBNOF-p4evkxjGo5+M0g@mail.gmail.com>
On Wed, 21 Mar 2012, Shaohua Li wrote:
> Holger uses raid for swap. We currently didn't do discard request
> merge as low SCSI driver doesn't allow. So for the raid0 case, we
> will split big discard request to chunk size, which is 512k. This will
> increase discard request number. This can be fixed later.
Are you sure that's a significant factor? I can certainly imagine it
magnifying the issue, but only Vertex2 has been reported as a problem.
> But on
> the other hand, if user doesn't explictly enable discard, why enable
> it? Like fs, we didn't do runtime discard and only run trim occasionally
Historic really: swap discard went in early, when it sounded like just
the right thing for swap, and we imagined that vendors would implement
it sensibly if they implemented it at all.
There appeared to be no need for such a flag at that time. But once
different firmwares appeared, and also block developers switched discard
over from using a barrier to waiting for completion, the use of discard
when allocating fresh clusters became often much slower: so we added the
flag for that case.
The use of discard at swapon time still appeared to be a worthwhile win,
not needing any flag: swapon is indeed occasional. But now the Vertex2
has shown just how unbearable that can be.
> since discard is slow.
On the Vertex2 - or do you know of others which pose this problem?
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-03-23 11:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-20 12:34 Shaohua Li
2012-03-20 18:21 ` Holger Kiehl
2012-03-20 19:42 ` Andrew Morton
2012-03-21 3:57 ` Hugh Dickins
2012-03-21 4:31 ` Shaohua Li
2012-03-21 4:56 ` Andrew Morton
2012-03-23 11:23 ` Hugh Dickins
2012-03-23 11:00 ` Hugh Dickins [this message]
2012-03-21 17:55 ` Holger Kiehl
2012-03-23 11:38 ` Hugh Dickins
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=alpine.LSU.2.00.1203230338110.31703@eggly.anvils \
--to=hughd@google.com \
--cc=Holger.Kiehl@dwd.de \
--cc=akpm@linux-foundation.org \
--cc=jmattax@storytotell.org \
--cc=linux-mm@kvack.org \
--cc=martin.petersen@oracle.com \
--cc=shli@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