Re: [PATCH, RFC 0/3] Introduce new O_HOT and O_COLD flags

[KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxx>]

(4/24/12 2:18 AM), Nick Piggin wrote:
> On 23 April 2012 21:47, Nick Piggin<npiggin@xxxxxxxxx>  wrote:
> > On 23 April 2012 18:23, James Bottomley
>
> > > Experience has taught me to be wary of fine grained hints: they tend to
> > > be more trouble than they're worth (the definitions are either
> > > inaccurate or so tediously precise that no-one can be bothered to read
> > > them).  A small set of broad hints is usually more useable than a huge
> > > set of fine grained ones, so from that point of view, I like the
> > > O_HOT/O_COLD ones.
> >
> > So long as the implementations can be sufficiently general that large majority
> > of "reasonable" application of the flags does not result in a slowdown, perhaps.
> >
> > But while defining the API, you have to think about these things and not
> > just dismiss them completely.
> >
> > Read vs write can be very important for caches and tiers, same for
> > random/linear,
> > latency constraints, etc. These things aren't exactly a huge unwieldy matrix. We
> > already have similar concepts in fadvise and such.
>
> I'm not saying it's necessarily a bad idea as such. But experience
> has taught me that if you define an API before having much
> experience of the implementation and its users, and without
> being able to write meaningful documentation for it, then it's
> going to be a bad API.
>
> So rather than pushing through these flags first, I think it would
> be better to actually do implementation work, and get some
> benchmarks (if not real apps) and have something working
> like that before turning anything into an API.

Fully agreed.

I _guess_ O_COLD has an enough real world usefullness because a backup operation
makes a lot of "write once read never" inodes. Moreover it doesn't have a system wide
side effect.

In the other hands, I don't imagine how O_HOT works yet. Beccause of, many apps want
to run faster than other apps and it definitely don't work _if_ all applications turn on
O_HOT for every open operations. So, I'm not sure why apps don't do such intentional
abuse yet.

So, we might need some API design discussions.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html