[RFC PATCH 0/3] um: clean up mm creation - another attempt

Anton Ivanov anton.ivanov at cambridgegreys.com
Mon Sep 25 08:20:54 PDT 2023


On 25/09/2023 15:44, Johannes Berg wrote:
> On Mon, 2023-09-25 at 15:27 +0100, Anton Ivanov wrote:
>> On 25/09/2023 14:33, Johannes Berg wrote:
>>> On Mon, 2023-09-25 at 14:29 +0100, Anton Ivanov wrote:
>>>> I have rebased the preempt patch on top of these series.
>>>>
>>>> PREEMPT works with some performance decrease.
>>>>
>>>> VOLUNTARY deadlocks early in boot around the time it starts loading modules.
>>>>
>>>> non-preemptible deadlocks very early in boot.
>>>>
>>> Well I guess that means there's still some issue in here? Hmm.
>>>
>>> Now I don't understand anything anymore, I guess.
>> PEBKAC. The tree got corrupted somewhere during rebase. Reapplying everything on top of a clean master fixed it.
>>
>> So it all works.
> OK, whew. At least now I no longer _completely_ doubt the mental model I
> have of UML VM :-)
>
>> With some performance penalties compared to the old approach, but works.
> I still find this odd though, I don't see what the flush would possibly
> do in a new (mm host) process that's not achievable in arch_dup_mmap()?
>
> OK, so let's see - arch_dup_mmap() is _earlier_ than the fork_handler,
> because that only happens on the very first switch into the process.
> This is only when it gets scheduled. So we'd be looking for something
> that copy_process() changes in the MM after copy_mm() and before it can
> get scheduled?
>
> I guess we could even move the flush it into copy_thread(), which is a
> simpler patch too, but it felt a bit wrong, since that's about the
> (guest!) process, not the mm.
>
> But basically I don't see anything there - fork syscall tail-calls
> kernel_clone(), which doesn't really do anything with the result of
> copy_process() except wake it up, and copy_process() doesn't really do
> anything either?

I am continuing to dig through that and looking for voluntary preemption points in the process.

We have none of our own and the generic ones are not invoked - voluntary for all practical purposes does not differ from no-preempt.

If I have some suspects, I will post their mugshots to the list :)

> johannes
>
-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/




More information about the linux-um mailing list