On Fri, Dec 11, 2015 at 11:25:54AM -0500, Tejun Heo wrote: > Hello, Peter, Ingo. > > On Wed, Nov 25, 2015 at 06:44:49PM +0100, Peter Zijlstra wrote: > > On Wed, Nov 25, 2015 at 06:31:41PM +0300, Andrey Ryabinin wrote: > > > > + /* scheduler bits, serialized by scheduler locks */ > > > > unsigned sched_reset_on_fork:1; > > > > unsigned sched_contributes_to_load:1; > > > > unsigned sched_migrated:1; > > > > + unsigned __padding_sched:29; > > > > > > AFAIK the order of bit fields is implementation defined, so GCC could > > > sort all these bits as it wants. > > > > We're relying on it doing DTRT in other places, so I'm fairly confident > > this'll work, otoh > > > > > You could use unnamed zero-widht bit-field to force padding: > > > > > > unsigned :0; //force aligment to the next boundary. > > > > That's a nice trick I was not aware of, thanks! > > Has this been fixed yet? While I'm not completely sure and I don't > think there's a way to be certain after the fact, we have a single > report of a machine which is showing ~4G as loadavg and one plausible > explanation could be that one of the ->nr_uninterruptible counters > underflowed from sched_contributes_to_load getting corrupted, so it'd > be great to get this one fixed soon. Nope, lemme write a Changelog and queue it. Thanks for the reminder. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>