lkml.org 
[lkml]   [2022]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] x86/sgx: Replace kmap/kunmap_atomic calls
From
On 10/6/22 15:02, Fabio M. De Francesco wrote:
> On Thursday, October 6, 2022 10:45:56 PM CEST Dave Hansen wrote:
> Am I still missing anything fundamental?

Yes. :)

kmap() users can sleep. That means the number of them that you need to
keep around is unbounded. kmap_atomic()'s fundamentally can't sleep so
you need fewer of them. That means that when you kunmap_atomic() you
can use a simple, fast, CPU-local TLB flushing operation. kunmap()
eventually requires a big fat global TLB flush.

So, you're right. On lowmem-only systems, kmap() *can* be cheaper than
kmap_atomic(). But, on highmem systems there's no contest:
kmap_atomic() is king.

That's why kmap_atomic() is and should be the default.

>> You use kmap_atomic() *always* unless you _need_ to sleep or one
>> of the other kmap()-only things.
>
> What would happen if you rely on switching in atomic as a side effect of
> kmap_atomic() and then you convert to kmap_local_page() without explicitly
> disabling, for example, preemption since who converts don't care to know if
> the code is in atomic before calling kmap_atomic() before or after the call
> (as I said there may be cases where non atomic execution must disable
> preemption for some reasons only between the mapping and the unmapping?
>
> If I were a maintainer I wouldn't trust changes that let me think that the
> developer can't tell if we need to disable something while converting to
> kmap_local_page().

In this case, it's just not that complicated. The SGX code isn't
relying on anything subtle that kmap_local_page() does not provide.

\
 
 \ /
  Last update: 2022-10-07 00:30    [W:0.044 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site