lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 12 Sep 2017 04:34:23 +0000
From:   Daeho Jeong <daeho.jeong@...sung.com>
To:     Jaegeuk Kim <jaegeuk@...nel.org>
CC:     "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-f2fs-devel@...ts.sourceforge.net" 
        <linux-f2fs-devel@...ts.sourceforge.net>
Subject: Re: [f2fs-dev] [PATCH] f2fs: fix double count on issued discard
 commands

> 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,

Powered by blists - more mailing lists