From: David Chow <davidchow@shaolinmicro.com>
To: Bryan Henderson <hbryan@us.ibm.com>
Cc: linux-fsdevel@vger.kernel.org, Neil Brown <neilb@cse.unsw.edu.au>
Subject: Re: buffer head read/write
Date: Wed, 11 Dec 2002 22:31:06 +0800 [thread overview]
Message-ID: <3DF74C2A.4080604@shaolinmicro.com> (raw)
In-Reply-To: OF0DD4434B.DD4F20EA-ON87256C8C.00005E0F-88256C8C.0001B123@us.ibm.com
OK, I think you know what I want, and you've just told me this is
impossible, then the best I could do is try to execute the task as best
as the CPU can. This is stolen from Neils md super block writing routing
that he just gave me a few days ago and merged with
wait_for_complettion. Does this code make sense?
static int sync_buffer_io(kdev_t dev, unsigned long sector, int size,
struct page *page, int rw)
struct buffer_head bh;
struct completion event;
init_completion(&event);
init_buffer(&bh, bh_complete, &event);
bh.b_rdev = dev;
bh.b_rsector = sector;
bh.b_state = (1 << BH_Req) | (1 << BH_Mapped);
bh.b_size = size;
bh.b_page = page;
bh.b_reqnext = NULL;
bh.b_data = page_address(page);
generic_make_request(rw, &bh);
run_task_queue(&tq_disk);
spin_lock_irq(even.wait.lock);
if (!event.done) {
DECLARE_WAITQUEUE(wait, current);
wait.flags |= WQ_FLAG_EXCLUSIVE;
__add_wait_queue_tail(event.wait, &wait);
do {
__set_current_state(TASK_UNINTERRUPTIBLE);
spin_unlock_irq(event.wait.lock);
run_task_queue(&tq_disk);
spin_lock_irq(event.wait.lock);
} while (!x->done);
__remove_wait_queue(event.wait, &wait);
}
event.done--;
spin_unlock_irq(&x->wait.lock);
return test_bit(BH_Uptodate, &bh.b_state);
}
This is dedicate to run the task of tq_disk instead of just schedule() which doesn't know
which task is going to run. Please comment. Thanks.
regards,
David
Bryan Henderson wrote:
>
>
>
>
>>I know how to make a call to general_make_request() but
>>wait for the buffer to complete which is too slow.
>>If I am doing a continuous sychronous read/write ..., can I put those
>>
>>
>"dirty
>
>
>>buffers"/"non-up-to-date buffers" in the head of the buffer queue so
>>that they get written by their respective handler immediately?
>>
>>
>
>"immediately" in computer systems normally means "while I wait" rather than
>"before doing anything else." That's why you got a bunch of answers that
>weren't what you were looking for.
>
>What you want is a way to assign priority to a block I/O request, so that
>a particular one gets executed first regardless of other factors, like
>that it's a mile away from where the head is now or 100 other requests
>came in before it. There's no way to do priority in today's block I/O
>layer.
>
>Incidentally, this has nothing to do with the buffer cache. The queue in
>question is for all I/O to a block device; it is below the buffer cache.
>
>
--
-----------------------------------------------------------------------------
David Chow | Managing Director
http://www.shaolinmicro.com
ShaoLin Microsystems - Multiply Efficiency
-----------------------------------------------------------------------------
next prev parent reply other threads:[~2002-12-11 14:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-09 16:25 buffer head read/write David Chow
2002-12-10 0:28 ` Bryan Henderson
2002-12-10 0:36 ` Neil Brown
2002-12-10 14:56 ` David Chow
2002-12-11 0:19 ` Bryan Henderson
2002-12-11 14:31 ` David Chow [this message]
2002-12-10 20:13 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3DF74C2A.4080604@shaolinmicro.com \
--to=davidchow@shaolinmicro.com \
--cc=hbryan@us.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).