On Tue, 13 Jun 2000, Steve Dodd wrote:
> On Mon, Jun 05, 2000 at 07:07:57AM +0200, Mike Galbraith wrote:
>
> > All I had to do to trigger the get_request problem was to do an iozone.
>
> Curiouser and curiouser..
>
> I played with iozone tonight on my victim box, booting with mem=8m seems to
> lead to loop device disaster pretty rapidly.. But this didn't seem to be
> a request issue. I had plugging disabled (I assume no other loop changes have
> gone into test1-ac, I've not caught up yet), and saw the following stack
> traces:
I did a quick check the other day, and the thing didn't blow up in my face.
That symptom was 'new' and seems to be gone. I also didn't hit the lockup.
The only thing I saw was buffers being trashed under memory pressure..
make bzImage worked fine, but make -jN bzImage didn't. I only did a very
quick status check though. (time time time)
> iozone process:
>
> schedule
> wakeup_bdflush
> refill_freelist
> getblk
> block_getblk
> ext2_get_block
> __block_prepare_write
> block_prepare_write
> ext2_prepare_write
> lo_send
> do_lo_request
> generic_make_request
> __ll_rw_block
> ll_rw_block
> sync_page_buffers
> try_to_free_buffers
> shrink_mmap
> do_try_to_free_pages
> try_to_free_pages
> __alloc_pages
> generic_file_write
> sys_write
>
> kswapd:
>
> schedule
> wakeup_bdflush
> refill_freelist
> getblk
> block_getblk
> ext2_get_block
> __block_prepare_write
> block_prepare_write
> ext2_prepare_write
> lo_send
> do_lo_request
> generic_make_request
> __ll_rw_block
> ll_rw_block
> sync_page_buffers
> try_to_free_buffers
> shrink_mmap
> do_try_to_free_pages
> kswapd
>
> kflushd:
>
> schedule
> __find_lock_page
> grab_cache_page
> lo_send
> do_lo_request
> generic_make_request
> __ll_rw_block
> ll_rw_block
> flush_dirty_buffers
> bdflush
>
>
> In other words, ext2 had a page locked but ran out of buffers trying to do
> I/O on it, and attempts by bdflush to free any end up with us waiting for
> that page to be unlocked..
This looks to me like the 'recursion' thing I mentioned.. all three are
trying to diddle the same data I think. Sleeping in getblk in a driver
is a bummer.. while you are _trying_ to do your job and get the thing
written to undirty, bdflush and/or kswapd (caused by allocation attempt
above) jump in and tell you to do what you are already doing. I got past
this by special casing loopdev buffers in try_to_free_buffers (other ways
too).. but that leads to oom because you can gererate dirty buffers faster
than you can sync them. (waiting for io on write would help that I think)
> I guess the next thing I'm going to try is Jens' [k]loopd patch, but even
> with that I'm not convinced there aren't a whole load of resource (buffer,
> buffer head, request) starvation problems.
I've been playing with ideas (reading/thinking) for not using getblk for
exactly these reasons.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:30 EST