Re: kernel-side thread stack swapping
On 9/2/22, Konstantin Belousov wrote: > On Fri, Sep 02, 2022 at 04:11:40PM +0200, Mateusz Guzik wrote: >> On 9/2/22, Konstantin Belousov 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
Re: kernel-side thread stack swapping
On Fri, Sep 02, 2022 at 04:11:40PM +0200, Mateusz Guzik wrote: > On 9/2/22, Konstantin Belousov 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.
Re: kernel-side thread stack swapping
On 9/2/22, Konstantin Belousov 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. -- Mateusz Guzik
Re: kernel-side thread stack swapping
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.
kernel-side thread stack swapping
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? -- Mateusz Guzik
