Christoph wrote:I'm confused. If B is the default, then we don't need a flag to enable it, rather we need a flag to go back to the old choice A. So are you saying that: 1) Choice A remains the default for the kernel unless MPOL_MF_RELATIVE is added, or 2) that the new default for the kernel is Choice B, unless MPOL_MF_RELATIVE is specified, asking to revert to the original Choice A behaviour? Perhaps, either way, whatever compatibility flag we have should be something that can be forced on an application from the outside, perhaps as a per-system mode flag in /sys, or a per-cpuset mode flag, or a per-task operation, by what mechanism is not clear. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 -
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Vu Pham | Re: [Scst-devel] Integration of SCST in the mainstream Linux kernel |
| Adrian Bunk | Re: Linux 2.6.21 |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Radu Rendec | Endianness problem with u32 classifier hash masks |
| Benjamin Herrenschmidt | [PATCH 0/11] ibm_newemac: Candidate patches for 2.6.25 |
