On 9/2/22, Konstantin Belousov <kostik...@gmail.com> wrote: > On Fri, Sep 02, 2022 at 04:11:40PM +0200, Mateusz Guzik wrote: >> On 9/2/22, Konstantin Belousov <kostik...@gmail.com> wrote: >> > On Fri, Sep 02, 2022 at 02:05:37PM +0200, Mateusz Guzik wrote: >> >> Is this really of practical use today? >> >> >> >> I have a WIP patch which needs to temporarily store something on the >> >> stack and should things go wrong enough it will be accessed by UMA, >> >> which can't handle the fault nor decide to skip the access. >> >> >> >> I can add something like td_pinstack or whatever to keep it around, >> >> but perhaps the entire machinery can be just whacked? >> > p_hold already does that. >> > >> >> I only need to protect the one stack and more importantly don't want >> to take the proc lock to bump p_hold (nor convert it to atomics), it's >> all thread-local so to speak. > > You do not want to take proc lock, or cannot? Note that only sleeping > thread' stack can be swapped out. >
To add some context here I'm looking at reworking vnode batching in vdrop -> vdbatch_enqueue to remove vnode interlock -> vdbatch lock -> vnode list lock dependency (and improve scalability of the thing). Adding a proc lock here would negatively affect performance for everyone *and* weirdly serialize same-proc consumers. -- Mateusz Guzik <mjguzik gmail.com>