linux-kernel - Re: [PATCH] fadvise: perform WILLNEED readahead in a workqueue

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]

Message-ID: <20121216052302.GA6680@dcvr.yhbt.net>
Date:	Sun, 16 Dec 2012 05:23:02 +0000
From:	Eric Wong <normalperson@...t.net>
To:	Dave Chinner <david@...morbit.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fadvise: perform WILLNEED readahead in a workqueue

Dave Chinner <david@...morbit.com> wrote:
> On Sun, Dec 16, 2012 at 03:35:49AM +0000, Eric Wong wrote:
> > Dave Chinner <david@...morbit.com> wrote:
> > > On Sun, Dec 16, 2012 at 12:25:49AM +0000, Eric Wong wrote:
> > > > Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> > > > > On Sat, 15 Dec 2012 00:54:48 +0000
> > > > > Eric Wong <normalperson@...t.net> wrote:
> > > > > 
> > > > > > Applications streaming large files may want to reduce disk spinups and
> > > > > > I/O latency by performing large amounts of readahead up front
> 
> > This could also be a use case for an audio/video player.
> 
> Sure, but this can all be handled by a userspace application. If you
> want to avoid/batch IO to enable longer spindown times, then you
> have to load the file into RAM somewhere, and you don't need special
> kernel support for that.

>From userspace, I don't know when/if I'm caching too much and possibly
getting the userspace cache itself swapped out.

> > So no, there's no difference that matters between the approaches.
> > But I think doing this in the kernel is easier for userspace users.
> 
> The kernel provides mechanisms for applications to use. You have not
> mentioned anything new that requires a new kernel mechanism to
> acheive - you just need to have the knowledge to put the pieces
> together properly.  People have been solving this same problem for
> the last 20 years without needing to tweak fadvise(). Or even having
> an fadvise() syscall...

fadvise() is fairly new, and AFAIK few apps use it.  Perhaps if it
were improved, more people would use it and not have to reinvent
the wheel.

> Nothing about low latency IO or streaming IO is simple or easy, and
> changing how readahead works doesn't change that fact. All it does
> is change the behaviour of every other application that uses
> fadvise() to minimise IO latency....

I don't want to introduce regressions, either.

Perhaps if part of the FADV_WILLNEED read-ahead were handled
synchronously (maybe 2M?) and humongous large readaheads (like mine)
went to the background, that would be a good trade off?
--
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/