lkml.org 
[lkml]   [2014]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] [PATCH] Pre-emption control for userspace
    On 03/03/2014 10:07 AM, Khalid Aziz wrote:
    >
    > I am working on a feature that has been requested by database folks that
    > helps with performance. Some of the oft executed database code uses
    > mutexes to lock other threads out of a critical section. They often see
    > a situation where a thread grabs the mutex, runs out of its timeslice
    > and gets switched out which then causes another thread to run which
    > tries to grab the same mutex, spins for a while and finally gives up.
    > This can happen with multiple threads until original lock owner gets the
    > CPU again and can complete executing its critical section. This queueing
    > and subsequent CPU cycle wastage can be avoided if the locking thread
    > could request to be granted an additional timeslice if its current
    > timeslice runs out before it gives up the lock. Other operating systems
    > have implemented this functionality and is used by databases as well as
    > JVM. This functionality has been shown to improve performance by 3%-5%.
    >
    > I have implemented similar functionality for Linux. This patch adds a
    > file /proc/<tgid>/task/<tid>/sched_preempt_delay for each thread.
    > Writing 1 to this file causes CFS scheduler to grant additional time
    > slice if the currently running process comes up for pre-emption. Writing
    > to this file needs to be very quick operation, so I have implemented
    > code to allow mmap'ing /proc/<tgid>/task/<tid>/sched_preempt_delay. This
    > allows a userspace task to write this flag very quickly. Usage model is
    > a thread mmaps this file during initialization. It then writes a 1 to
    > the mmap'd file after it grabs the lock in its critical section where it
    > wants immunity from pre-emption. It then writes 0 again to this file
    > after it releases the lock and calls sched_yield() to give up the
    > processor. I have also added a new field in scheduler statistics -
    > nr_preempt_delayed, that counts the number of times a thread has been
    > granted amnesty. Further details on using this functionality are in
    > Documentation/scheduler/sched-preempt-delay.txt in the patch. This
    > patch is based upon the work Venkatesh Pallipadi had done couple of
    > years ago.
    >

    Shades of the Android wakelocks, no?

    This seems to effectively give userspace an option to turn preemptive
    multitasking into cooperative multitasking, which of course is
    unacceptable for a privileged process (the same reason why unprivileged
    processes aren't allowed to run at above-normal priority, including RT
    priority.)

    I have several issues with this interface:

    1. First, a process needs to know if it *should* have been preempted
    before it calls sched_yield(). So there needs to be a second flag set
    by the scheduler when granting amnesty.

    2. A process which fails to call sched_yield() after being granted
    amnesty must be penalized.

    3. I'm not keen on occupying a full page for this. I'm wondering if
    doing a pointer into user space, futex-style, might make more sense.
    The downside, of course, is what happens if the page being pointed to is
    swapped out.

    Keep in mind this HAS to be per thread.

    -hpa




    \
     
     \ /
      Last update: 2014-03-04 23:41    [W:4.405 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site