[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: svs_pmap_sync() svs_pdir_switch() overhead
Le 24/05/2020 à 23:49, Andrew Doran a écrit :
On Sun, May 24, 2020 at 09:42:33PM +0000, Andrew Doran wrote:
On Sat, May 23, 2020 at 09:04:26AM +0200, Maxime Villard wrote:
Le 20/05/2020 ? 11:12, Manuel Bouyer a ?crit?:
On Tue, May 19, 2020 at 10:51:52PM +0000, Andrew Doran wrote:
Both of these show up prominently in profiling for me. This change largely
I didn't know kcpuset_isotherset() existed, that is indeed better.
Not sure the second part is correct though. Suppose:
cpu0 is executing svs_pdir_switch(), and cpu1 is modifying the PTEs at the
same time. cpu0 returns to userland before cpu1 finished. [XXX]. cpu1
finishes, and calls svs_pmap_sync().
In the [XXX] window, the PTEs could be used by userland. If you copied
them using memcpy(), some parts of the bytes could contain stale values.
You mean if memcpy() was moving single bytes at a time? That won't happen,
Ah I see the compiler is up to its tricks here, so the assumption is not
quite so safe, and despite usually being very clever it's memset is daft.
The removal of bcopy(), bcmp() and bzero() was a mistake. Anyway I'll do
Overall I think this reasoning is bad. If you want to have stuff copied in
an atomic-safe manner, then use an atomic function; don't rely on some wild
assumptions that just won't hold after the next compiler update.
Besides, bcopy and the like do not guarantee that they do operations on
quads, so using bcopy wouldn't have been more correct than memcpy.
Main Index |
Thread Index |