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. Thanks. -- tejun -- 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>