lkml.org 
[lkml]   [2023]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED
    On 11/09/2023 4:04 pm, Peter Zijlstra wrote:
    > On Sun, Sep 10, 2023 at 11:32:32AM -0700, Linus Torvalds wrote:
    >
    >> I was hoping that we'd have some generic way to deal with this where
    >> we could just say "this thing is reschedulable", and get rid of - or
    >> at least not increasingly add to - the cond_resched() mess.
    > Isn't that called PREEMPT=y ? That tracks precisely all the constraints
    > required to know when/if we can preempt.
    >
    > The whole voluntary preempt model is basically the traditional
    > co-operative preemption model and that fully relies on manual yields.
    >
    > The problem with the REP prefix (and Xen hypercalls) is that
    > they're long running instructions and it becomes fundamentally
    > impossible to put a cond_resched() in.

    Any VMM - Xen isn't special here.

    And if we're talking about instructions, then CPUID, GETSEC and
    ENCL{S,U} and plenty of {RD,WR}MSRs in in a similar category, being
    effectively blocking RPC operations to something else in the platform.

    The Xen evtchn upcall logic in Linux does cond_resched() when possible. 
    i.e. long-running hypercalls issued with interrupts enabled can
    reschedule if an interrupt occurs, which is pretty close to how REP
    works too.

    ~Andrew

    \
     
     \ /
      Last update: 2023-09-12 00:03    [W:5.123 / U:0.792 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site