Re: CONFIG_PREEMPT and server workloads

[Andrea Arcangeli]

On Thu, Mar 18, 2004 at 10:47:29AM -0800, Andrew Morton wrote:
> Andrea Arcangeli <andrea@xxxxxxx> wrote:
> >
> > > hand so we should only fall into the kmap() if the page was suddenly stolen
> >  > again.
> > 
> >  Oh so you mean the page fault insn't only interrupting the copy-user
> >  atomically, but the page fault is also going to sleep and pagein the
> >  page? I though you didn't want to allow other tasks to steal the kmap
> >  before you effectively run the kunmap_atomic. I see it can be safe if
> >  kunmap_atomic is a noop though, but you're effectively allowing
> >  scheduling inside a kmap this way.
> 
> No, we don't schedule with the atomic kmap held.  What I meant was:

good to hear this (even scheduling inside an atomic kmap could be made
to work but I would find it less obviously safe since kumap_atomic would
need to be a noop for example).

> 
> 	get_user(page);		/* fault it in */
> 	kmap_atomic(page);
> 	if (copy_from_user(page))
> 		goto slow_path;
> 	kunmap_atomic(page);
> 
> 	...
> 
> slow_path:
> 	kunmap_atomic(page);
> 	kmap(page);
> 	copy_from_user(page);
> 	kunmap(page);
> 

I see what you mean now, so you suggest to run an unconditional
get_user(). It's hard to tell here, I agree the cost would be nearly
zero since the loaded byte from memory it'll go into l1 cache and it
would avoid a page fault in some unlikely case compared to what I
proposed, but I don't like too much it because I really like to optimize
as much as possible for the fast path always, so I still like to keep
the get_user out of the fast path. But you're right to argue since it's
hard to tell what's better in practice (certainly one could write a
malicious load where the additional pagefault could be measurable, while
the get_user would always be hardly measurable).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/