On Tue 10-05-11 10:40:37, Mel Gorman wrote:
On Fri, Apr 29, 2011 at 12:28:50PM +0200, Michal Hocko wrote:
On Thu 28-04-11 13:35:13, Jeff Mahoney wrote: [...]
Mel Gorman / Michal Hocko: - - patches.fixes/grab-swap-token-oops
There are still no in-kernel users of gup from kernel threads AFAICS. Besides that I think there is no issue in the current upstream because we do not get to handle_mm_fault (and grab_swap_token) path if there is no mm_struct. find_extend_vma will return NULL for (mm == NULL) and so we either go into gate_vma path (which is not handled by the patch and still can be an issue because of pgd_offset_gate) or fail with -EFAULT.
The same applies to openSUSE-11.4 and SLES10_SP4_BRANCH branches. If Mel doesn't see anything I would vote for dropping the patch from all supported branches.
That patch belongs to an SGI developer so there is a possibility that they have an RDMA driver or MPI accelerator that was doing direct writes to userspace after pinning the page with get_user_pages(). GPFS could also be doing weird things from kernel threads and pinning pages for IO a kernel thread context.
Then we should keep the patch. We shouldn't risk any "regression" even though they might be bugs in the external code. Thanks for the clarification I missed that 3rd party modules can really matter here. [...]
- - patches.suse/files-slab-rcu.patch
Nick's VFS black magic. The patch is not applied in openSUSE-11.4. Sorry, I cannot say anything about this patch.
Drop it unless there is a known specific use case it helps. There is now a whole host of other VFS black magic merged to mainline and it improves open/close performance in other ways. Slab-destroy-by-rcu means there is a variable amount of time spent freeing slab objects. Many users probably don't care, but realtime people have complained about variable latency when freeing slab objects before and this is the kind of thing that can surprise them.
Jack should have pinged Nick about this one so I would rather wait for what he comes with.
- - patches.suse/mm-devzero-optimisation.patch [against SLES10, issue may not exist anymore]
Yes we can drop it from SLE11-SP1 and openSUSE-11.4 branches. The zero page has been reintroduced in 2.6.32. The main reason for the above patch was the page fault overhead (coming from allocation and zeroing) during copying from /dev/zero. Now that we have zero page again this is not a case anymore so we do not need any special /dev/zero hacks.
Sure.
Removed from SLE11-SP1 (SP2 will get it automatically), openSUSE.11.3, openSUSE.11.4 and master branches.
- - patches.fixes/aggressive-zone-reclaim.patch [disabled since 2.6.36]
I assume that the patch has been reverted due to changes in the area, right?
It's not clear. I think it might have been dropped due to conflicts and there was no motivation to keep it updated.
My impression of the patch is that is highly workload specific.
Extremely so.
Especially decreasing ZONE_RECLAIM_PRIORITY to 0 is very tricky because it makes reclaim really aggressive. I think this part is highly controversial for upstream.
It would only make sense on a machine running threads that were tightly bound to their NUMA node which will probably only be tree on HPC configurations. For things like mail servers running on Nehalem with large NUMA distances, this patch could have very surprising results.
Nevertheless, I quite like the ZONE_RECLAIM_LOCKED part. Although, this can be really subtle because we might end up reclaiming too much if there is really heavy parallel load or multiple high order allocators.
Yes.
A consequence of removing it is that a number of parallel allocator requests that happen at the same time dump all the memory of a node. Worse, they could start reclaiming each others memory in the node which would manifest as unexpected stalls at unpredictable times. This is true for normal reclaim of course but in __zone_reclaim it's potentially worse as it's focusing on clean pages.
I will wait with reverting for Mel but mm-devzero-optimisation.patch is one that can go away for sure.
Ditch it. It is likely to adversely affect common workloads that are heavily file based.
OK. I will keep it for for SLE11-SP[12] because we had an L3 request for it and it fixed a real problem that our customer saw and nobody complained about massive zone reclaim so far. I will remove it from other branches (master, openSUSE.11.[34]). Thanks -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org