On Wed, 10 May 2000, BenHanokh Gabriel wrote:
> animesh_singh@bbv.satyam.com wrote:
>
> > On Tue, 9 May 2000, Gabriel Benhanokh wrote:
> >
> > >
> > > >
> > > > hi
> > > > very true i missed out a few more details , the buffer block after
> > > > being marked uptodate is also required to wake up any process sleeping on
> > > > its wait queue this is done by execution of b_end_io function in the
> > > > buffer head (ll_rw_blk) but this is all done only when the buffer block
> > > > has been flushed by bdflush or sync command line(this generates request
> > > > for the under laying disk driver by make_request) and successfully written
> > > > on the disk.
> > > > a very simple solution for your problem can be one of these
> > > > 1. you don't allow your buffer block to be ever processed by ll_rw_blk
> > > > function hence always mark it uptodate , wake up all waiting process and
> > > > not dirty
> > > how do i do this?
> > > will maring the buffer clean and than calling bforget won't do this ?
> >
> > have a look at the
> > end_that_request_last function defined in the ll_rw_blk.c
> > the wait queue is associated with request issued to the device
> > it came here in the first place because the block asked for was
> > not there in the buffer cache (bread returns immediately if the
> > block is present else issues the request for it)hence its
> > necessary to wakeup all these process
> >
>
> i didn't see who is calling the end_that_request_last function, it is not being
> called by the ll_rw_blk or the make_reqest functions
> should i call it myself?
not needed make_request will call it internally
end_that_request_last is usually executed by the driver itself
look in ide.c and associated files (it indicates completion of
requests thus awaking all processes sleeping on request's wait
queue)
>
> >
> > >
> > > > 2. you trap the request call at disk driver level(this is fairly easy) and
> > > > don't allow the block to be written but call end_request(1)(this does
> > > > everything for you) without executing the real request function of the
> > > > disk driver thus data is never written
> > > i think that this will only help not to do the disk io, but won't avoid the
> > > cache wiping problem. i will still be using too many un-nessceary cache
> > > buffers.
> > > and beside for this i must change the driver which i don't want.
> > > i'm trying to just add another module without changing any other stuff.
> > >
> > No !!!!!
> > you don't have to do all this ,
> > request function of all the block devices are registered in
> > request structure are part of the
> > struct blk_dev_struct blk_dev (look in ll_rw_blk.c)
> > blk_dev is an exposed DS thus its easy to steal the request
> > function pointer and substitute your own function ptr here , thus
> > a simple module can do all the job for you (i have some code if
> > you want i shall send it )
> >
> > in order to release your buffer block its necessary to reduce its
> > b_count to zero hence followed by any reference to buffer block
> > through apis like bread shuold be followed by brelse. even though
> > you might find that the buffers are still persisting they shall all be
> > eatten away when any heavy mem requirements are put to your system
>
> ok, i checked it up and it looks like there is no need to override the
> make_request function, it checks for the dirty bit before attemting to write, and
> if it is clean it jumps directly to the end_io: label which calls the b_end_io
> so i guess that using
> mark_buffer_uptodate( bh )
> mark_buffer_clean( bh )
>
> will prevent the buffer from being ever written to the disk.
>
Every true
> but how do i recycle the buffer head? do i need to call brelease or bforget ? or
call brelse takes care of all conditions and safe
> that the make_request will take care for this ?
no
> do i need to call end_that_request_last ?
no make_request internally calls it on completion of last buffer
request
> THX
> /gaby
>
>
> -
> 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/
>
-
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 : Mon May 15 2000 - 21:00:15 EST