On Sat, 21 Oct 2000, Mike Galbraith wrote:
> On Sat, 21 Oct 2000, Mike Galbraith wrote:
>
> > On Fri, 20 Oct 2000, Mark Hahn wrote:
> >
> > > > This is something that has been bugging me for a while. I notice
> > > > on my system that during disk write we do much context switching,
> > > > but not during disk read. Why is that?
> > >
> > > bdflush is broken in current kernels. I posted to linux-mm about this,
> > > but Rik et al haven't shown any interest. I normally see bursts of
> > > up to around 40K cs/second when doing writes; I hacked a little
> > > premption counter into the kernel and verified that they're practially
> > > all bdflush...
> >
> > P.S.
> >
> > I took a ktrace snapshot of iozone doing 8k writes. This seems like
> > a strange and expensive way to only unplug a device ;-) Anyone know
> > why?
Hi self :) You think I know now, so let's ask Rik.
> > c010a976 system_call +<22/40> (0.16) pid(257)
> > c0131bc0 sys_write +<10/d8> (0.12) pid(257)
> > ...
> > c010a99a ret_from_sys_call +<6/19> (0.20) pid(257)
> > c0117f7b schedule +<13/404> (2.14) pid(257->5)
> > c01091a3 __switch_to +<13/cc> (1.16) pid(5)
> > c01888c6 generic_unplug_device +<e/38> (0.27) pid(5)
> > c0117f7b schedule +<13/404> (0.51) pid(5->257)
> > c01091a3 __switch_to +<13/cc> (0.30) pid(257)
> > c010a99a ret_from_sys_call +<6/19> (1.20) pid(257)
>
> (arg!) P.P.S
>
> That was perhaps too brief to be clear exactly what I mean.
>
> In a trace segment 263 milliseconds long we switch to kflushd
> 279 times. 251 of 279 cases are exactly the above.
Greetings Rik,
Because it's seemingly stuck in __get_request_wait(). Under heavy
I/O, this means that page_launder() isn't going to be able to do
anything for extended periods of time. Doesn't this mean that bdflush
isn't a good place to do asychronous scrubbing?
I moved it into __alloc_pages() in place of wakeup_bdflush(). It
doesn't seem to either help or hurt anything though :-/.
-Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
