mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@sophos.com>
To: Eric Paris <eparis@redhat.com>
Cc: John Stoffel <john@stoffel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"agruen@suse.de" <agruen@suse.de>
Subject: Re: Linux 2.6.36-rc7
Date: Mon, 18 Oct 2010 12:01:52 +0100	[thread overview]
Message-ID: <201010181201.53883.tvrtko.ursulin@sophos.com> (raw)
In-Reply-To: <1286556106.2682.66.camel@localhost.localdomain>

On Friday 08 Oct 2010 17:41:46 Eric Paris wrote:
> On Fri, 2010-10-08 at 17:17 +0100, Tvrtko Ursulin wrote:
> > On Friday 08 Oct 2010 16:42:06 John Stoffel wrote:
> >
> > Priority is also not that great concept. I may have proposed classes or
> > something similar at some point, don't remember any more. It would be
> >
> > equivalent to having allocated priority ranges, like:
> > >1000 - pre-content
> > >=100 - access-control
> >
> > <100 - content
> >
> > Doesn't really solve ordering inside groups so maybe we do not need
> > priorities at all just these three classes?
>
> I originally thought of trying to enumerate the types of users and came
> up with the same 3 you did.  Then I thought it better to give a general
> priority field which we could indicate in documentation something like
> those 3 classes (exactly like you did above).  I don't want to hard code
> some limited number of types of users into the interface. (ok it's going
> to limited, I was thinking 8 bits, but maybe others think we need more?)
>
> As an extreme example going with 3 fixed type of users (and thus
> equivalently only 3 priorities) would not allow for hierarchies of
> hierarchical storage managers.  What if priority MAX only brought in
> enough info for priority MAX-1 to bring in the real file?  If they had
> to share the single 'pre-content' priority we have another ordering
> problem.

I think I am fine with priorities if we make these three ranges documented.

Ordering between ranges, like in your chained HSM setup, would then be
sysadmin's responsibility but those setups look esoteric enough to think we
could get away with it. More importantly, I really do not see an automatic
solution which would solve all imaginable (more or less crazy) setups one
could come up with and priorities solve all normal ones plus giving some more
options than having only three classes.

If you go with 8 bits, you could even have classes plus priorities. Like
having low bits for in-class priority and then high two or three for class
(three if with a single bit set in class field implementation would be more
efficient). I do not see any usability advantage of this scheme though, it
just may enable an implementation with less decisions based on arbitrary
numbers.

Tvrtko

Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.

  reply	other threads:[~2010-10-18 11:01 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-06 21:45 Linus Torvalds
2010-10-07  0:49 ` Stephen Rothwell
2010-10-08 15:05   ` James Bottomley
2010-10-07 16:10 ` Tvrtko Ursulin
2010-10-07 17:15   ` Tvrtko Ursulin
2010-10-07 17:33     ` Eric Paris
2010-10-07 18:07       ` Alan Cox
2010-10-07 17:49         ` Eric Paris
2010-10-08 12:06           ` Andreas Gruenbacher
2010-10-08 16:33             ` David Daney
2010-10-08 21:50               ` Andreas Gruenbacher
2010-10-08 21:59                 ` H. Peter Anvin
2010-10-11 22:13                   ` fanotify: disable fanotify syscalls Eric Paris
2010-10-08 16:38             ` Linux 2.6.36-rc7 Eric Paris
2010-10-08 21:45               ` Andreas Gruenbacher
2010-10-07 20:55       ` John Stoffel
2010-10-07 21:24         ` Eric Paris
2010-10-08 15:42           ` John Stoffel
2010-10-08 16:17             ` Tvrtko Ursulin
2010-10-08 16:41               ` Eric Paris
2010-10-18 11:01                 ` Tvrtko Ursulin [this message]
2010-10-08 16:54               ` John Stoffel
2010-10-08 21:03               ` Andreas Gruenbacher
2010-10-09  0:46                 ` John Stoffel
2010-10-07 19:28 ` Tejun Heo
2010-10-07 20:13   ` [dm-devel] " Milan Broz
2010-10-08 17:02     ` Tejun Heo
2010-10-10 11:56       ` Torsten Kaiser
2010-10-11 10:09       ` [PATCH wq#for-next] workqueue: fix HIGHPRI handling in keep_working() Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201010181201.53883.tvrtko.ursulin@sophos.com \
    --to=tvrtko.ursulin@sophos.com \
    --cc=agruen@suse.de \
    --cc=eparis@redhat.com \
    --cc=john@stoffel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome