On Tue, Jan 15, 2013 at 05:21:15PM -0800, Sonny Rao wrote: > On Tue, Jan 15, 2013 at 4:50 PM, Andrew Morton > <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 15 Jan 2013 16:32:38 -0800 > > Sonny Rao <sonnyrao@xxxxxxxxxx> wrote: > > > >> >> It's for saving the power to increase batter life. > >> > > >> > It might well have that effect, dunno. That wasn't my intent. Testing > >> > needed! > >> > > >> > >> Power saving is certainly why we had it on originally for ChromeOS, > >> but we turned it off due to misbehavior. > >> > >> Specifically, we saw a pathological behavior where we'd end up writing > >> to the disk every few seconds when laptop mode was turned on. This > >> turned out to be because laptop-mode sets a timer which is used to > >> check for new dirty data after the initial flush and writes that out > >> before spinning the disk down, and on ChromeOS various chatty daemons > >> on the system were logging and dirtying data more or less constantly > >> so there was almost always something there to be written out. So what > >> ended up happening was that we'd need to do a read, then wake up the > >> disk, and then keep writing every few seconds for a long period of > >> time, which had the opposite effect from what we wanted. > > > > So after the read, the disk would chatter away doing a dribble of > > writes? That sounds like plain brokenness (and why did the chrome guys > > not tell anyone about it?!?!?). > > Yes, either read or fsync. I ranted about it a little (here: > http://marc.info/?l=linux-mm&m=135422986220016&w=4), but mostly > assumed it was working as expected, and that ChromeOS was just > dirtying data at an absurd pace. Might have been a bad assumption and > I could have been more explicit about reporting it, sorry about that. > > > The idea is that when the physical > > read occurs, we should opportunistically flush out all pending writes, > > while the disk is running. Then go back into > > buffer-writes-for-a-long-time mode. > > > > See the comment in page-writeback.c above laptop_io_completion(): > > /* > * We've spun up the disk and we're in laptop mode: schedule writeback > * of all dirty data a few seconds from now. If the flush is already > scheduled > * then push it back - the user is still using the disk. > */ > void laptop_io_completion(struct backing_dev_info *info) > > What ends up happening fairly often is that there's always something > dirty with that few seconds (or even one second) on our system. > > > I forget what we did with fsync() and friends. Quite a lot of > > pestiferous applications like to do fsync quite frequently. I had a > > special kernel in which fsync() consisted of "return 0;", but ISTR > > there being some resistance to productizing that idea. > > > > Yeah, we have this problem and we try to fix up users of fsync() as we > find them but it's a bit of a never-ending battle. Such a feature > would be useful. > > >> The issues > >> with zram swap just confirmed that we didn't want laptop mode. > >> > >> Most of our devices have had SSDs rather than spinning disks, so noise > >> wasn't an issue, although when we finally did support an official > >> device with a spinning disk people certainly complained when the disk > >> started clicking all the time > > > > hm, it's interesting that the general idea still has vailidity. It > > would be a fun project for someone to sniff out all the requirements, > > fixup/enhance/rewrite the current implementation and generally make it > > all spiffy and nice. > > > >> (due to the underflow in the writeback code). > > > > To what underflow do you refer? > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=c8b74c2f6604923de91f8aa6539f8bb934736754 > > That particular bug caused writes to happen almost instantly after the > underflow ocurred, and consequently slowed write throughput to a crawl > because there was no chance for contiguous writes to gather. > > >> We do know that current SSDs save a significant amount of > >> power when they go into standby, so minimizing disk writes is still > >> useful on these devices. > >> > >> A very simple laptop mode which only does a single sync when we spin > >> up the disk, and didn't bother with the timer behavior or muck with > >> swap behavior might be something that is more useful for us, and I > >> suspect it might simplify the writeback code somewhat as well. > > > > I don't think I understand the problem with the timer. My original RFC > > said > > > > : laptop_writeback_centisecs > > : -------------------------- > > : > > : This tunable determines the maximum age of dirty data when the machine > > : is operating in Laptop mode. The default value is 30000 - five > > : minutes. This means that if applications are generating a small amount > > : of write traffic, the disk will spin up once per five minutes. > > : > > : If the disk is spun up for any other reason (such as for a read) then > > : all dirty data will be flushed anyway, and this timer is reset to zero. > > > > which all sounds very sensible and shouldn't exhibit the behavior you > > observed. > > > > The laptop-mode timer get re-armed after each writeback (see above > laptop_io_completion function), even if it was caused by laptop-mode > itself. So, if something is continually dirtying a little bit of > data, we end up getting a chain of small writes which keeps the disk > awake for long periods of time. Out of curiosity, for saving the power, why don' you increase the value for laptop_mode? > > -- > 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> -- Kind regards, Minchan Kim -- 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>