linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* schedule/sleep over mmget()
@ 2020-06-18 15:20 Jens Axboe
  2020-06-19 11:43 ` Michal Hocko
  0 siblings, 1 reply; 3+ messages in thread
From: Jens Axboe @ 2020-06-18 15:20 UTC (permalink / raw)
  To: linux-mm

Hi,

Got a question that I couldn't immediately find an answer to. io_uring
currently jumps through a few hoops to avoid holding a process mm over
schedule, and it doesn't look like that's necessary.

Is it fine for a kthread to do mmget/kthread_use_mm at the start, and
only put/unuse when it exits? Or is it more prudent to drop/re-acquire
over schedule for potential longer periods of idleness?

Thanks,
-- 
Jens Axboe



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: schedule/sleep over mmget()
  2020-06-18 15:20 schedule/sleep over mmget() Jens Axboe
@ 2020-06-19 11:43 ` Michal Hocko
  2020-06-19 13:59   ` Jens Axboe
  0 siblings, 1 reply; 3+ messages in thread
From: Michal Hocko @ 2020-06-19 11:43 UTC (permalink / raw)
  To: Jens Axboe; +Cc: linux-mm

On Thu 18-06-20 09:20:40, Jens Axboe wrote:
> Hi,
> 
> Got a question that I couldn't immediately find an answer to. io_uring
> currently jumps through a few hoops to avoid holding a process mm over
> schedule, and it doesn't look like that's necessary.
> 
> Is it fine for a kthread to do mmget/kthread_use_mm at the start, and
> only put/unuse when it exits? Or is it more prudent to drop/re-acquire
> over schedule for potential longer periods of idleness?

Pinning the address space for a long time is not really ideal. This
would prevent quite  a lot of memory to be released when the primary
owner of the address space goes away (willingly or by the OOM killer).
Our documentation says
 * Never use this function to pin this address space for an
 * unbounded/indefinite amount of time.

If you know the kthread is not going to use the mm for some time just
pin the mm struct itsef by mmgrab() and then mmget_not_zero() to get the
address space for your use again.
-- 
Michal Hocko
SUSE Labs


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: schedule/sleep over mmget()
  2020-06-19 11:43 ` Michal Hocko
@ 2020-06-19 13:59   ` Jens Axboe
  0 siblings, 0 replies; 3+ messages in thread
From: Jens Axboe @ 2020-06-19 13:59 UTC (permalink / raw)
  To: Michal Hocko; +Cc: linux-mm

On 6/19/20 5:43 AM, Michal Hocko wrote:
> On Thu 18-06-20 09:20:40, Jens Axboe wrote:
>> Hi,
>>
>> Got a question that I couldn't immediately find an answer to. io_uring
>> currently jumps through a few hoops to avoid holding a process mm over
>> schedule, and it doesn't look like that's necessary.
>>
>> Is it fine for a kthread to do mmget/kthread_use_mm at the start, and
>> only put/unuse when it exits? Or is it more prudent to drop/re-acquire
>> over schedule for potential longer periods of idleness?
> 
> Pinning the address space for a long time is not really ideal. This
> would prevent quite  a lot of memory to be released when the primary
> owner of the address space goes away (willingly or by the OOM killer).
> Our documentation says
>  * Never use this function to pin this address space for an
>  * unbounded/indefinite amount of time.

OK, and that's what I've been adhering to. BTW, while checking for this,
the use case in drivers/vhost/vhost.c does not seem to be playing nice.

> If you know the kthread is not going to use the mm for some time just
> pin the mm struct itsef by mmgrab() and then mmget_not_zero() to get the
> address space for your use again.

Yep, that's what I'm currently doing. The "normal" io_uring case is that
when the process exits, the ring goes away anyway. So for most setups,
we should be fine pinning it, but there are also setups where that's not
the case.

-- 
Jens Axboe



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-06-19 14:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-18 15:20 schedule/sleep over mmget() Jens Axboe
2020-06-19 11:43 ` Michal Hocko
2020-06-19 13:59   ` Jens Axboe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).