That's OK. PF_NOIO is a 2.4 "oh shit" for a loop driver deadlock.
That all just fixed itself up.
> - Writeback: instead of forcing reinstating a page on the
> inactive list when !PageActive, page->mapping, !Pagedirty, and
> !PageWriteback (see mm/page-writeback.c, fs/mpage.c), I just
> let it go without any LRU list changes. If the page is
> inactive and needs attention, it'll end up on the inactive
> dirty list soon anyway, AFAICT. Seems okay so far, but that
> may be flawed/sloppy reasoning... We could always look at the
> page flags and reinstate the page to the appropriate LRU list
> (i.e. inactive clean or dirty) if this turns out to be a
The thinking there was this: the 2.4 shrink_cache() code was walking the
LRU, running writepage() against dirty pages at the tail. Each written
page was moved to the head of the LRU while under writeout, because we
can't do anything with it yet. Get it out of the way.
When I changed that single-page writepage() into a "clustered 32-page
writeout via ->dirty_pages", the same thing had to happen: get those
pages onto the "far" end of the inactive list.
So basically, you'll need to give them the same treatment as Rik
was giving them when they were written out in vmscan.c. Whatever
that was - it's been a while since I looked at rmap, sorry.
> - To be consistent with 2.4-rmap, this patch includes a
> minimal BIO-ified port of Andrew Morton's read-latency2 patch
> (i.e. minus the elvtune ioctl stuff) to 2.5, from his patch
> sets. This adds about 7 kB to the patch.
Heh. Probably we should not include this in your patch. It gets
in the way of evaluating rmap. I suggest we just suffer with the
existing IO scheduling for the while ;)
> - The patch also includes compilation fixes:
> drivers/scsi/constants.c (undeclared integer variable)
> drivers/pci/pci-driver.c (unresolved symbol in pcmcia_core)
> include/linux/smp.h (define cpu_online_map for UP)
> kernel/ksyms.c (export default_wake_function for modules)
> arch/i386/i386_syms.c (export ioremap_nocache for modules)
> Hope this is of use to someone! It's certainly been a fun and
> instructive exercise for me so far. ;)
Good stuff, thanks.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/