* [RFC][PATCH 2.6.0-test2] get rid of unused request_queue field queue_wait
@ 2003-07-28 8:03 Lou Langholtz
2003-07-28 12:18 ` Jens Axboe
0 siblings, 1 reply; 3+ messages in thread
From: Lou Langholtz @ 2003-07-28 8:03 UTC (permalink / raw)
To: linux-kernel, Jens Axboe, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
Are we going to use the queue_wait field of struct request_queue
someday? As of 2.6.0-test2, I don't see any use of it. If it's not
needed anymore, the following patch gets rid of it. Tested this patch by
compiling for i386 and also doing a grep through all .h and .c files to
see if it's used somewhere else (admittedly weak).
[-- Attachment #2: patch-2.6.0-test2-no_queue_wait --]
[-- Type: text/plain, Size: 893 bytes --]
diff -urN linux-2.6.0-test2/drivers/block/ll_rw_blk.c linux-2.6.0-test2-no_queue_wait/drivers/block/ll_rw_blk.c
--- linux-2.6.0-test2/drivers/block/ll_rw_blk.c 2003-07-27 19:02:48.000000000 -0600
+++ linux-2.6.0-test2-no_queue_wait/drivers/block/ll_rw_blk.c 2003-07-27 22:36:16.000000000 -0600
@@ -225,7 +225,6 @@
*/
blk_queue_bounce_limit(q, BLK_BOUNCE_HIGH);
- init_waitqueue_head(&q->queue_wait);
INIT_LIST_HEAD(&q->plug_list);
}
diff -urN linux-2.6.0-test2/include/linux/blkdev.h linux-2.6.0-test2-no_queue_wait/include/linux/blkdev.h
--- linux-2.6.0-test2/include/linux/blkdev.h 2003-07-27 19:02:52.000000000 -0600
+++ linux-2.6.0-test2-no_queue_wait/include/linux/blkdev.h 2003-07-27 22:18:19.000000000 -0600
@@ -337,8 +337,6 @@
unsigned long seg_boundary_mask;
unsigned int dma_alignment;
- wait_queue_head_t queue_wait;
-
struct blk_queue_tag *queue_tags;
/*
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC][PATCH 2.6.0-test2] get rid of unused request_queue field queue_wait
2003-07-28 8:03 [RFC][PATCH 2.6.0-test2] get rid of unused request_queue field queue_wait Lou Langholtz
@ 2003-07-28 12:18 ` Jens Axboe
2003-07-28 13:20 ` Jens Axboe
0 siblings, 1 reply; 3+ messages in thread
From: Jens Axboe @ 2003-07-28 12:18 UTC (permalink / raw)
To: Lou Langholtz; +Cc: linux-kernel, Andrew Morton
On Mon, Jul 28 2003, Lou Langholtz wrote:
> Are we going to use the queue_wait field of struct request_queue
> someday? As of 2.6.0-test2, I don't see any use of it. If it's not
> needed anymore, the following patch gets rid of it. Tested this patch by
> compiling for i386 and also doing a grep through all .h and .c files to
> see if it's used somewhere else (admittedly weak).
It's a relic from before dynamic request allocation, for now it can
definitely go.
--
Jens Axboe
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC][PATCH 2.6.0-test2] get rid of unused request_queue field queue_wait
2003-07-28 12:18 ` Jens Axboe
@ 2003-07-28 13:20 ` Jens Axboe
0 siblings, 0 replies; 3+ messages in thread
From: Jens Axboe @ 2003-07-28 13:20 UTC (permalink / raw)
To: Lou Langholtz; +Cc: linux-kernel, Andrew Morton
On Mon, Jul 28 2003, Jens Axboe wrote:
> On Mon, Jul 28 2003, Lou Langholtz wrote:
> > Are we going to use the queue_wait field of struct request_queue
> > someday? As of 2.6.0-test2, I don't see any use of it. If it's not
> > needed anymore, the following patch gets rid of it. Tested this patch by
> > compiling for i386 and also doing a grep through all .h and .c files to
> > see if it's used somewhere else (admittedly weak).
>
> It's a relic from before dynamic request allocation, for now it can
> definitely go.
Eh sorry, still very much jet lagged. It has nothing to do with request
allocation. The point still stands though, it can be removed.
--
Jens Axboe
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-07-28 13:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-28 8:03 [RFC][PATCH 2.6.0-test2] get rid of unused request_queue field queue_wait Lou Langholtz
2003-07-28 12:18 ` Jens Axboe
2003-07-28 13:20 ` Jens Axboe
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).