linux-kernel - Re: [PATCH v2 01/16] FS: Added demand paging markers to filesystem

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 9 May 2012 13:59:40 +0000
From:	Arnd Bergmann <arnd.bergmann@...aro.org>
To:	Dave Chinner <david@...morbit.com>
Cc:	"S, Venkatraman" <svenkatr@...com>, linux-mmc@...r.kernel.org,
	cjb@...top.org, linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	alex.lemberg@...disk.com, ilan.smith@...disk.com,
	lporzio@...ron.com, rmk+kernel@....linux.org.uk
Subject: Re: [PATCH v2 01/16] FS: Added demand paging markers to filesystem

On Wednesday 09 May 2012, Dave Chinner wrote:
> > In low end flash devices, some requests might take too long than normal
> > due to background device maintenance (i.e flash erase / reclaim procedure)
> > kicking in in the context of an ongoing write, stalling them by several
> > orders of magnitude.
> 
> And thereby stalling what might be writes critical to operation.
> Indeed, how does this affect the system when it starts swapping
> heavily? If you keep stalling writes, the system won't be able to
> swap and free memory...

The point here is that reads have a consistent latency, e.g. 500
microseconds for a small access, while writes have a latency
that can easily become 1000x the read latency (e.g. 500 ms of
blocking the device) depending on the state of the device. Most
of the time, writes are fast as well, but sometimes (when garbage
collection happens in the device), they are extremely slow and
block everything else.
This is the only time we ever want to interrupt a write: keeping
the system running interactively while eventually getting to do
the writeback. There is a small penalty for interrupting the garbage
collection, but the device should be able to pick up its work
at the point where we interrupt it, so we can still make forward
progress.

> > > This really seems like functionality that belongs in an IO
> > > scheduler so that write starvation can be avoided, not in high-level
> > > data read paths where we have no clue about anything else going on
> > > in the IO subsystem....
> > 
> > Indeed, the feature is built mostly in the low level device driver and
> > minor changes in the elevator. Changes above the block layer are only
> > about setting
> > attributes and transparent to their operation.
> 
> The problem is that the attribute you are setting covers every
> single data read that is done by all users. If that's what you want
> to have happen, then why do you even need a new flag at this layer?
> Just treat every non-REQ_META read request as a demand paged IO and
> you've got exactly the same behaviour without needing to tag at the
> higher layer....

My feeling is that we should just treat every (REQ_SYNC | REQ_READ)
request the same and let them interrupt long-running writes,
independent of whether it's REQ_META or demand paging.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/