linux-kernel - Re: [RFC PATCH 1/5] block, ioprio: include caching advice via ionice

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: <CAPcyv4hgeoGJMG3aAb4auQj+bwnv4J__AkC_MvRHWdNP9gOGPg@mail.gmail.com>
Date:	Wed, 29 Oct 2014 14:07:58 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	"Jason B. Akers" <jason.b.akers@...el.com>,
	"IDE/ATA development list" <linux-ide@...r.kernel.org>,
	axboe@...com, "Karkra, Kapil" <kapil.karkra@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/5] block, ioprio: include caching advice via ionice

On Wed, Oct 29, 2014 at 12:02 PM, Jeff Moyer <jmoyer@...hat.com> wrote:
> "Jason B. Akers" <jason.b.akers@...el.com> writes:
>
>> From: Dan Williams <dan.j.williams@...el.com>
>>
>> Steal one unused bit from the priority class and two bits from the
>> priority data, to implement a 3 bit cache-advice field.  Similar to the
>> page cache advice from fadvise() these hints are meant to be consumed
>> by hybrid drives.  Solid State Hyrbid-Drives, as defined by the SATA-IO
>> Specification, implement up to a 4-bit cache priority that can be
>> specified along with a FPDMA command.
>
> ionice is about setting an I/O scheduling class for a *process*.  So,
> unless I've missed something, this does not seem like the right
> interface for passing I/O hints.
>
> You mention fadvise hints, which sounds like a good fit (and madvise
> would be equally interesting), but I don't see where you've wired them
> up in this patch set.  Did I miss it?

It turns out we didn't need it.  It's straightforward to add, but I
think "80%" of the benefit can be had by just having a per-thread
cache priority.  It's more powerful to say "any page cache page this
thread touches, or any direct i/o this thread does, goes down the
stack at the given priority".
--
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/