Messages in this thread | | | Date | Wed, 3 Mar 2004 21:10:42 -0800 | From | Andrew Morton <> | Subject | Re: 2.4.23aa2 (bugfixes and important VM improvements for the high end) |
| |
Andrea Arcangeli <andrea@suse.de> wrote: > > On Wed, Mar 03, 2004 at 08:07:04PM -0800, Andrew Morton wrote: > > That's a larger difference than I expected. But then, everyone has been > > mysql is threaded
There is a patch in -mm's 4g/4g implementation (4g4g-locked-userspace-copy.patch) which causes all kernel<->userspace copies to happen under page_table_lock. In some threaded apps on SMP this is likely to cause utterly foul performance.
That's why I'm keeping it as a separate patch. The problem which it fixes is very obscure indeed and I suspect most implementors will simply drop it after they'e had a two-second peek at the profile results.
hm, I note that the changelog in that patch is junk. I'll fix that up.
Something like:
The current 4g/4g implementation does not guarantee the atomicity of mprotect() on SMP machines. If one CPU is in the middle of a read() into a user memory region and another CPU is in the middle of an mprotect(!PROT_READ) of that region, it is possible for a race to occur which will result in that read successfully completing _after_ the other CPU's mprotect() call has returned.
We believe that this could cause misbehaviour of such things as the boehm garbage collector. This patch provides the mprotect() atomicity by performing all userspace copies under page_table_lock.
It is a judgement call. Personally, I wouldn't ship a production kernel with this patch. People need to be aware of the tradeoff and to think and test very carefully.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |