[PATCH 0/13] Turn hrtimers into a range capable timer - Kernel

This is a discussion on [PATCH 0/13] Turn hrtimers into a range capable timer - Kernel ; On Tue, 02 Sep 2008 10:22:12 +0200 Peter Zijlstra wrote: > On Mon, 2008-09-01 at 16:08 -0700, Arjan van de Ven wrote: > > > @@ -847,7 +847,8 @@ static void enqueue_hrtimer(struct hrtimer > > *timer, > > * We ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 44

Thread: [PATCH 0/13] Turn hrtimers into a range capable timer

  1. Re: [PATCH 11/13] hrtimer: turn hrtimers into range timers

    On Tue, 02 Sep 2008 10:22:12 +0200
    Peter Zijlstra wrote:

    > On Mon, 2008-09-01 at 16:08 -0700, Arjan van de Ven wrote:
    >
    > > @@ -847,7 +847,8 @@ static void enqueue_hrtimer(struct hrtimer
    > > *timer,
    > > * We dont care about collisions. Nodes with
    > > * the same expiry time stay together.
    > > */
    > > - if (timer->expires.tv64 < entry->expires.tv64) {
    > > + if (hrtimer_get_expires_tv64(timer) <
    > > + hrtimer_get_expires_tv64(entry)) {
    > > link = &(*link)->rb_left;
    > > } else {
    > > link = &(*link)->rb_right;

    >
    > On Mon, 2008-09-01 at 16:13 -0700, Arjan van de Ven wrote:
    >
    > > +static inline void hrtimer_set_expires_range(struct hrtimer
    > > *timer, ktime_t time, ktime_t delta) +{
    > > + timer->_softexpires = time;
    > > + timer->_expires = ktime_add_safe(time, delta);
    > > +}

    >
    > > @@ -241,10 +259,19 @@ static inline ktime_t
    > > hrtimer_get_expires(const struct hrtimer *timer) return
    > > timer->_expires; }
    > >
    > > +static inline ktime_t hrtimer_get_softexpires(const struct hrtimer
    > > *timer) +{
    > > + return timer->_expires;
    > > +}

    >
    > Somehow the function is called softexpires, but returns the hard
    > expire time...


    argh that's what you get if you split a patch into a series by hand ;-(

    > > ktime_sub(hrtimer_get_expires(timer),

    >
    > I might be missing something, but this code only looks at the leftmost
    > timer, and we're indexed on the hard expire time, which might be
    > rather far to the right of here.
    >
    > This means that esp for those timers for which we can save most we're
    > least likely to do so because we'll plain not see them.


    you're missing a little detail

    yes we start from left to right, and we stop once we find a timer that
    we can't fire anymore. The thing that you missed is that any timer
    after that (even if we could fire it now) will just be fired when the
    timer we stopped on fires.. so it'll still group them around those
    timers that are otherwise ungroupable.
    (it's not perfect by any means but it works ;-)

    >
    >
    >



    --
    If you want to reach me at my work email, use arjan@linux.intel.com
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 11/13] hrtimer: turn hrtimers into range timers

    On Tue, 2008-09-02 at 06:05 -0700, Arjan van de Ven wrote:
    > On Tue, 02 Sep 2008 10:22:12 +0200
    > Peter Zijlstra wrote:
    >
    > > On Mon, 2008-09-01 at 16:08 -0700, Arjan van de Ven wrote:
    > >
    > > > @@ -847,7 +847,8 @@ static void enqueue_hrtimer(struct hrtimer
    > > > *timer,
    > > > * We dont care about collisions. Nodes with
    > > > * the same expiry time stay together.
    > > > */
    > > > - if (timer->expires.tv64 < entry->expires.tv64) {
    > > > + if (hrtimer_get_expires_tv64(timer) <
    > > > + hrtimer_get_expires_tv64(entry)) {
    > > > link = &(*link)->rb_left;
    > > > } else {
    > > > link = &(*link)->rb_right;

    > >
    > > On Mon, 2008-09-01 at 16:13 -0700, Arjan van de Ven wrote:
    > >
    > > > +static inline void hrtimer_set_expires_range(struct hrtimer
    > > > *timer, ktime_t time, ktime_t delta) +{
    > > > + timer->_softexpires = time;
    > > > + timer->_expires = ktime_add_safe(time, delta);
    > > > +}

    > >
    > > > @@ -241,10 +259,19 @@ static inline ktime_t
    > > > hrtimer_get_expires(const struct hrtimer *timer) return
    > > > timer->_expires; }
    > > >
    > > > +static inline ktime_t hrtimer_get_softexpires(const struct hrtimer
    > > > *timer) +{
    > > > + return timer->_expires;
    > > > +}

    > >
    > > Somehow the function is called softexpires, but returns the hard
    > > expire time...

    >
    > argh that's what you get if you split a patch into a series by hand ;-(
    >
    > > > ktime_sub(hrtimer_get_expires(timer),

    > >
    > > I might be missing something, but this code only looks at the leftmost
    > > timer, and we're indexed on the hard expire time, which might be
    > > rather far to the right of here.
    > >
    > > This means that esp for those timers for which we can save most we're
    > > least likely to do so because we'll plain not see them.

    >
    > you're missing a little detail
    >
    > yes we start from left to right, and we stop once we find a timer that
    > we can't fire anymore. The thing that you missed is that any timer
    > after that (even if we could fire it now) will just be fired when the
    > timer we stopped on fires.. so it'll still group them around those
    > timers that are otherwise ungroupable.
    > (it's not perfect by any means but it works ;-)


    Gah, right. How about adding the following:

    /*
    * The immediate goal is minimizing wakeups, not running
    * timers at the earliest interrupt after their soft expiration.
    * This allows us to avoid using a Priority Search Tree,
    * which can answer a stabbing querry for overlapping
    * intervals and instead use the simple BST we already have.
    * We don't add extra wakeups by delaying timers that are
    * right-of a not yet expired timer, because that timer will
    * have to trigger a wakeup anyway.
    */



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

  3. Re: [PATCH 11/13] hrtimer: turn hrtimers into range timers

    On Tue, 02 Sep 2008 15:47:07 +0200
    Peter Zijlstra wrote:

    > > (it's not perfect by any means but it works ;-)

    >
    > Gah, right. How about adding the following:
    >
    > /*
    > * The immediate goal is minimizing wakeups, not running
    > * timers at the earliest interrupt after their soft expiration.
    > * This allows us to avoid using a Priority Search Tree,
    > * which can answer a stabbing querry for overlapping
    > * intervals and instead use the simple BST we already have.
    > * We don't add extra wakeups by delaying timers that are
    > * right-of a not yet expired timer, because that timer will
    > * have to trigger a wakeup anyway.
    > */


    fair enough; I'll merge this in (I'm not going to resend the whole
    series just for this redo though... maybe when there's more feedback
    I'll roll it all up)
    thanks!

    --
    If you want to reach me at my work email, use arjan@linux.intel.com
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH 13/13] hrtimer: make select() and poll() use the hrtimer range feature

    On Tue, 02 Sep 2008 10:22:20 +0200
    Peter Zijlstra wrote:

    > Why not use a simple logarithmic decay to drive this estimate?


    or just take a 0.1% of the time

    Linus wrote the original, who am I to argue?
    (and arguably, it doesn't really matter much, the current code is nice
    and simple enough)


    --
    If you want to reach me at my work email, use arjan@linux.intel.com
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH 0/13] Turn hrtimers into a range capable timer


    hi Arjan,

    * Arjan van de Ven wrote:

    > This series is a follow-on the the nanosecond select/poll series.
    >
    > The goal of this series is to introduce the capability into hrtimers
    > to deal with a "range" rather than a specific point in time. (Several
    > people discussed this recently, but we've been toying with the concept
    > for a while)


    i've started doing some QA of this series in -tip.

    it has a new -git based topic: tip/timers/range-hrtimers.

    testing found this build failure:

    In file included from include/linux/sched.h:87,
    from arch/x86/kernel/asm-offsets_32.c:9,
    from arch/x86/kernel/asm-offsets.c:3:
    include/linux/hrtimer.h: In function 'hrtimer_start_expires':
    include/linux/hrtimer.h:359: error: implicit declaration of function 'hrtimer_get_expires'
    include/linux/hrtimer.h:359: error: incompatible type for argument 2 of 'hrtimer_start'
    4.69user 2.38system 0:13.19elapsed 53%CPU (0avgtext+0avgdata 0maxresident)k

    with the attached config.

    Ingo


  6. Re: [PATCH 0/13] Turn hrtimers into a range capable timer

    On Sat, 6 Sep 2008 16:56:10 +0200
    Ingo Molnar wrote:

    >
    > hi Arjan,
    >
    > * Arjan van de Ven wrote:
    >
    > > This series is a follow-on the the nanosecond select/poll series.
    > >
    > > The goal of this series is to introduce the capability into
    > > hrtimers to deal with a "range" rather than a specific point in
    > > time. (Several people discussed this recently, but we've been
    > > toying with the concept for a while)

    >
    > i've started doing some QA of this series in -tip.
    >
    > it has a new -git based topic: tip/timers/range-hrtimers.
    >
    > testing found this build failure:
    >


    ok I fixed this in the master branch of
    git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-hrtimer.git
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH 0/13] Turn hrtimers into a range capable timer


    * Arjan van de Ven wrote:

    > ok I fixed this in the master branch of
    > git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-hrtimer.git


    thanks, pulled. Next build failure is:

    In file included from include/linux/sched.h:87,
    from arch/x86/kernel/asm-offsets_32.c:9,
    from arch/x86/kernel/asm-offsets.c:3:
    include/linux/hrtimer.h: In function 'hrtimer_is_hres_active':
    include/linux/hrtimer.h:211: error: 'struct hrtimer_cpu_base' has no member named 'hres_active'
    include/linux/hrtimer.h: At top level:
    include/linux/hrtimer.h:316: error: redefinition of 'hrtimer_cb_get_time'
    include/linux/hrtimer.h:205: error: previous definition of 'hrtimer_cb_get_time' was here
    include/linux/hrtimer.h:321: error: redefinition of 'hrtimer_is_hres_active'
    include/linux/hrtimer.h:210: error: previous definition of 'hrtimer_is_hres_active' was here

    config attached.

    i've pushed out the broken tree into tip/tmp.broken.range-hrtimers

    Ingo.


  8. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    Hi!

    > > and this makes really ugly interface.

    >
    > prctl() is ugly?


    for something like this... yes.

    > >
    > > ...plus it bloats task struct.
    > >
    > > ...where did the sys_indirect proposals go? We created new syscalls,
    > > right?

    >
    > ... which nobody uses today.
    > It's not just new syscalls, it's a new glibc api as well at that point.


    ....and new applications, yes. I believe applications should
    explicitely enable slacking timers.
    Pavel

    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    On Mon, 8 Sep 2008 15:27:16 +0200
    Pavel Machek wrote:
    > >
    > > ... which nobody uses today.
    > > It's not just new syscalls, it's a new glibc api as well at that
    > > point.

    >
    > ...and new applications, yes. I believe applications should
    > explicitely enable slacking timers.


    timers are slacking today, at least for select() and poll(), and are a
    great deal more so than the defaults in this patchkit.

    The great advantage of the prctl() approach (which is usable) over new
    system calls and glibc APIs is that it will get used, because the admin
    can use it just like he uses the "nice" command, on existing software.


    --
    If you want to reach me at my work email, use arjan@linux.intel.com
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    On Mon 2008-09-08 06:40:02, Arjan van de Ven wrote:
    > On Mon, 8 Sep 2008 15:27:16 +0200
    > Pavel Machek wrote:
    > > >
    > > > ... which nobody uses today.
    > > > It's not just new syscalls, it's a new glibc api as well at that
    > > > point.

    > >
    > > ...and new applications, yes. I believe applications should
    > > explicitely enable slacking timers.

    >
    > timers are slacking today, at least for select() and poll(), and are a
    > great deal more so than the defaults in this patchkit.


    Ok, so select()/poll() may default to non-zero slack for legacy apps.

    > The great advantage of the prctl() approach (which is usable) over new
    > system calls and glibc APIs is that it will get used, because the admin
    > can use it just like he uses the "nice" command, on existing software.


    Yes, it is a great advantage, but it feels like a hack. Maybe it is
    better done with LD_PRELOAD or something?

    I'd certianly want the applications to specify slack themselves in
    like 10 years.

    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    On Mon, 8 Sep 2008 16:15:55 +0200
    Pavel Machek wrote:

    > On Mon 2008-09-08 06:40:02, Arjan van de Ven wrote:
    > > On Mon, 8 Sep 2008 15:27:16 +0200
    > > Pavel Machek wrote:
    > > > >
    > > > > ... which nobody uses today.
    > > > > It's not just new syscalls, it's a new glibc api as well at that
    > > > > point.
    > > >
    > > > ...and new applications, yes. I believe applications should
    > > > explicitely enable slacking timers.

    > >
    > > timers are slacking today, at least for select() and poll(), and
    > > are a great deal more so than the defaults in this patchkit.

    >
    > Ok, so select()/poll() may default to non-zero slack for legacy apps.


    that's whats there
    >
    > > The great advantage of the prctl() approach (which is usable) over
    > > new system calls and glibc APIs is that it will get used, because
    > > the admin can use it just like he uses the "nice" command, on
    > > existing software.

    >
    > Yes, it is a great advantage, but it feels like a hack. Maybe it is
    > better done with LD_PRELOAD or something?


    that's not working very well in general, and doesn't work across exec
    etc.

    >
    > I'd certianly want the applications to specify slack themselves in
    > like 10 years.


    We've been talking to Ulrich to figure out what the right API for this
    is (eg how to extend select/poll for this) and I still plan to work on
    this, but both Linus and Ulrich seem to be very ademant that it means
    only few apps will use it (and I agree with that, just look at how many
    apps use linux specific APIs such as sendfile(), linux AIO etc... )


    --
    If you want to reach me at my work email, use arjan@linux.intel.com
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH 0/13] Turn hrtimers into a range capable timer

    On Tuesday 02 September 2008 09:03:43 Arjan van de Ven wrote:
    > This series is a follow-on the the nanosecond select/poll series.
    >
    > The goal of this series is to introduce the capability into hrtimers to
    > deal with a "range" rather than a specific point in time.
    > (Several people discussed this recently, but we've been toying with the
    > concept for a while)


    Hi Arjen, sorry for not replying sooner.

    I had half a patch to create a new "timer layer to rule them all" called
    ktimers, which took an explicit "slop" value. Slop is the "how long before
    its worth waking the machine for this?" value, with friendly SLOP_USECS,
    SLOP_SECONDS, SLOP_DAYS etc defines. Implemented in terms of normal and hr
    timers, which get deprecated over time.

    Heuristics work for a while, but IMHO eventually this is going to have to be
    plumbed through to userspace.

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

  13. Re: [PATCH 0/13] Turn hrtimers into a range capable timer

    On Fri, 12 Sep 2008 13:39:49 +1000
    Rusty Russell wrote:

    > On Tuesday 02 September 2008 09:03:43 Arjan van de Ven wrote:
    > > This series is a follow-on the the nanosecond select/poll series.
    > >
    > > The goal of this series is to introduce the capability into
    > > hrtimers to deal with a "range" rather than a specific point in
    > > time. (Several people discussed this recently, but we've been
    > > toying with the concept for a while)

    >
    > Hi Arjen, sorry for not replying sooner.
    >
    > I had half a patch to create a new "timer layer to rule them all"
    > called ktimers, which took an explicit "slop" value. Slop is the
    > "how long before its worth waking the machine for this?" value, with
    > friendly SLOP_USECS, SLOP_SECONDS, SLOP_DAYS etc defines.
    > Implemented in terms of normal and hr timers, which get deprecated
    > over time.
    >
    > Heuristics work for a while, but IMHO eventually this is going to
    > have to be plumbed through to userspace.


    yes we need to add the system calls at some point (beyond the prctl);
    however both Ulrich and Linus indicated that this will be one of those
    "handful of users" kind of things. IMO it needs to work well enough
    without having to change the whole application stack (and with my
    patches that can be done; it works well in practice)

    >
    > Cheers,
    > Rusty.



    --
    Arjan van de Ven Intel Open Source Technology Centre
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [PATCH 0/13] Turn hrtimers into a range capable timer

    On Fri, 12 Sep 2008, Rusty Russell wrote:
    > On Tuesday 02 September 2008 09:03:43 Arjan van de Ven wrote:
    > > This series is a follow-on the the nanosecond select/poll series.
    > >
    > > The goal of this series is to introduce the capability into hrtimers to
    > > deal with a "range" rather than a specific point in time.
    > > (Several people discussed this recently, but we've been toying with the
    > > concept for a while)

    >
    > Hi Arjen, sorry for not replying sooner.
    >
    > I had half a patch to create a new "timer layer to rule them all" called
    > ktimers, which took an explicit "slop" value. Slop is the "how long before


    Be warned, the name ktimers has already a bad history. Just ask the
    oracle of google

    > its worth waking the machine for this?" value, with friendly SLOP_USECS,
    > SLOP_SECONDS, SLOP_DAYS etc defines. Implemented in terms of normal and hr
    > timers, which get deprecated over time.
    >
    > Heuristics work for a while, but IMHO eventually this is going to have to be
    > plumbed through to userspace.


    Agreed.

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

  15. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    Hi!

    > > Yes, it is a great advantage, but it feels like a hack. Maybe it is
    > > better done with LD_PRELOAD or something?

    >
    > that's not working very well in general, and doesn't work across exec
    > etc.


    LD_PRELOAD should work over exec...

    Another possibility would be to declare new syscalls, and have glibc
    automatically use select_slack(, foo) if GLIBC_SLACK=foo.

    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    On Mon, Sep 8, 2008 at 7:15 AM, Pavel Machek wrote:
    > Ok, so select()/poll() may default to non-zero slack for legacy apps.


    That's the goal.

    > Yes, it is a great advantage, but it feels like a hack. Maybe it is
    > better done with LD_PRELOAD or something?
    >
    > I'd certianly want the applications to specify slack themselves in
    > like 10 years.


    LD_PRELOAD is not a solution. LD_PRELOAD always has been and always
    will be a hack. You use it to work around problems or to test
    something. Nothing else.

    LD_PRELOAD and other variables are ignored in security-relevant
    contexts and environments are cleared in many situations. Sure, you
    could use /etc/ld.so.preload but that works around only one problem.
    Furthermore, there is a significant cost associated with preloading.
    There are additional files to be loaded and it disables prelinking.

    The prctl() way plus a default non-zero value is the best way for
    legacy apps. And you'll hopefully get your wish that apps will take
    fate into their own hand by specifying the slack themselves. Arjan's
    proposal also introduces new poll/select-like interface which take the
    additional slack value (at least that's what we discussed before).

    I'm strongly opposed to using LD_PRELOAD. And I think requiring the
    libc implementation of select/ poll, ... etc to wrap around the new
    interfaces which take the slack and determine the slack at userlevel
    (by reading some file) is too expensive. It's one little value per
    process (group) to be kept by the kernel. That's not much.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    On Sun, 14 Sep 2008 08:21:26 -0700
    "Ulrich Drepper" wrote:

    > The prctl() way plus a default non-zero value is the best way for
    > legacy apps. And you'll hopefully get your wish that apps will take
    > fate into their own hand by specifying the slack themselves. Arjan's
    > proposal also introduces new poll/select-like interface which take the
    > additional slack value (at least that's what we discussed before).


    I have not posted the code for this yet (the patch set is huge
    already :0) but yes it's going to happen.
    You and I do need to figure out what a sensible interface will be for
    these ;-)


    --
    Arjan van de Ven Intel Open Source Technology Centre
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct


    > > Yes, it is a great advantage, but it feels like a hack. Maybe it is
    > > better done with LD_PRELOAD or something?
    > >
    > > I'd certianly want the applications to specify slack themselves in
    > > like 10 years.

    >
    > LD_PRELOAD is not a solution. LD_PRELOAD always has been and always
    > will be a hack. You use it to work around problems or to test
    > something. Nothing else.
    >
    > LD_PRELOAD and other variables are ignored in security-relevant
    > contexts and environments are cleared in many situations. Sure, you


    ....but that's okay, right? You would not want passwd to inherit huge
    slack specified by attacker...?

    > The prctl() way plus a default non-zero value is the best way for
    > legacy apps. And you'll hopefully get your wish that apps will take
    > fate into their own hand by specifying the slack themselves. Arjan's
    > proposal also introduces new poll/select-like interface which take the
    > additional slack value (at least that's what we discussed before).
    >
    > I'm strongly opposed to using LD_PRELOAD. And I think requiring the
    > libc implementation of select/ poll, ... etc to wrap around the new
    > interfaces which take the slack and determine the slack at userlevel
    > (by reading some file) is too expensive. It's one little value per
    > process (group) to be kept by the kernel. That's not much.


    Well, it is not too much, but... is the cost for userspace really
    significant? You'd clearly want it stored in environment, not
    filesystem...
    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    On Sun, Sep 14, 2008 at 8:57 AM, Pavel Machek wrote:
    >> LD_PRELOAD and other variables are ignored in security-relevant
    >> contexts and environments are cleared in many situations. Sure, you

    >
    > ...but that's okay, right? You would not want passwd to inherit huge
    > slack specified by attacker...?


    No, it's not OK. There are enough apps which are privileged and need
    to be handled this way. Take the X server, for instance.

    ]
    > Well, it is not too much, but... is the cost for userspace really
    > significant? You'd clearly want it stored in environment, not
    > filesystem...


    You cannot really use the environment for anything meaningful.
    Especially for this case, you couldn't change the setting for a
    running process. What a fully-userlevel implementation would have to
    do is read the value from a file and monitor the file for changes for
    every new poll/select call. That's a huge cost.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    On Sun, 14 Sep 2008 09:04:08 -0700
    "Ulrich Drepper" wrote:

    >
    > You cannot really use the environment for anything meaningful.
    > Especially for this case, you couldn't change the setting for a
    > running process. What a fully-userlevel implementation would have to
    > do is read the value from a file and monitor the file for changes for
    > every new poll/select call. That's a huge cost.


    in addition, the value really is per thread, not per process, and how
    do you want to do that with env. variables?

    --
    Arjan van de Ven Intel Open Source Technology Centre
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast