On Thu 20-12-12 21:36:58, Andy Lutomirski wrote: > On Thu, Dec 20, 2012 at 4:14 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Thu, Dec 20, 2012 at 03:10:10PM -0800, Andy Lutomirski wrote: > >> The onus is currently on filesystems to call file_update_time > >> somewhere in the page_mkwrite path. This is unfortunate for three > >> reasons: > >> > >> 1. page_mkwrite on a locked page should be fast. ext4, for example, > >> often sleeps while dirtying inodes. > > > > That's an ext4 problem, not a page fault or timestamp update > > problem. Fix ext4. > > I could fix ext4 (or rather, someone who understands jbd2 could fix > ext4), but I think my approach is considerably simpler and fixes all > filesystems at once. Well, you could implement the fix you did just inside ext4. Remove timestamp update from ext4_page_mkwrite(), just set some inode flag there, update times in ext4_writepages(), ext4_sync_file(), and ext4_release_file(). It won't be as elegant but it would work. > >> 3. (An ulterior motive) I'd like to use hardware dirty tracking for > >> shared, locked, writable mappings (instead of page faults). Moving > >> important work out of the page_mkwrite path is an important first step. > > > > I don't think you're going to get very far doing this. page_mkwrite > > needs to do: > > > > a) block allocation in page_mkwrite() for faults over holes > > to detect ENOSPC conditions immediately rather than in > > writeback when such an error results in data loss. > > b) detect writes over unwritten extents so that the pages in > > the page cache can be set up correctly for conversion to > > occur during writeback. > > > > Correcting these two problems was the reason for introducing > > page_mkwrite in the first place - we need to do this stuff before > > the page fault is completed, and that means, by definition, > > page_mkwrite needs to be able to block. Moving c/mtime updates out > > of the way does not, in any way, change these requirements. > > I was unclear. I have no problem if PROT_WRITE, MAP_SHARED pages > start out write protected. I want two changes from the status quo, > though: > > 1. ptes (maybe only if mlocked or maybe even only if some new madvise > flag is set) should be marked clean but stay writable during and after > writeback. (This would only work when stable pages are not in > effect.) This is actually problematic - s390 architecture doesn't have PTE dirty bit. It has per page HW dirty bit but that's problematic to use so it's completely relying on page being protected after writeback so that it hits page fault when it should be dirtied again. Also memory management uses these page faults to track number of dirty pages which is then important to throttle aggressive writers etc. (we used to do what you describe sometimes in early 2.6 days but then we switched to writeprotecting the page for writeback to be able to do dirty page tracking). If we limit the behavior you desribe to mlocked pages, I could imagine things would work out from the accounting POV (we could treat mlocked pages as always dirty for accounting purposes) but it's definitely not a change to be easily made. > 2. There should be a way to request that pages be made clean-but-writable. > > #1 should be mostly fine already from the filesystems' point of view. > #2 would involve calling page_mkwrite or some equivalent. > > I suspect that there are bugs that are currently untriggerable > involving clean-but-writable pages. For example, what happens if cpu > 0 (atomically) changes a pte from clean/writable to not present, but > cpu 1 writes the page before the TLB flush happens. I think the pte > ends up not present + dirty, but the current unmapping code won't > notice. > > This would involve splitting page_mkclean into "make clean and write > protect" and "make clean but leave writable". > > Doing this would avoid ~1M "soft" page faults per day in a single > real-time thread in my software. (The file time patches are to make > sure that the "soft" page faults actually don't sleep.) Yes, there's a non-negligible cost of writeprotecting the page during writeback. But the avoidance of OOM conditions due to too aggressive writers simply has precedence... Anyway, if you want to push more in this direction, I suggest to move this discussion to linux-mm@xxxxxxxxx as there are lingering more appropriate listeners :). I'm just a filesystem guy with some basic knowledge of MM. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
