[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANfBPZ-V86XfnA8CXVsupvWkfnXPC7upCqAFsx8+_2Ta5zTabA@mail.gmail.com>
Date: Thu, 3 May 2012 21:52:32 +0530
From: "S, Venkatraman" <svenkatr@...com>
To: Jeff Moyer <jmoyer@...hat.com>
Cc: linux-mmc@...r.kernel.org, cjb@...top.org, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, linux-omap@...r.kernel.org,
linux-kernel@...r.kernel.org, arnd.bergmann@...aro.org,
alex.lemberg@...disk.com, ilan.smith@...disk.com,
lporzio@...ron.com, rmk+kernel@....linux.org.uk
Subject: Re: [PATCH v2 06/16] block: treat DMPG and SWAPIN requests as special
On Thu, May 3, 2012 at 8:08 PM, Jeff Moyer <jmoyer@...hat.com> wrote:
> Venkatraman S <svenkatr@...com> writes:
>
>> From: Ilan Smith <ilan.smith@...disk.com>
>>
>> When exp_swapin and exp_dmpg are set, treat read requests
>> marked with DMPG and SWAPIN as high priority and move to
>> the front of the queue.
>>
> [...]
>> + if (bio_swapin(bio) && blk_queue_exp_swapin(q)) {
>> + spin_lock_irq(q->queue_lock);
>> + where = ELEVATOR_INSERT_FLUSH;
>> + goto get_rq;
>> + }
>> +
>> + if (bio_dmpg(bio) && blk_queue_exp_dmpg(q)) {
>> + spin_lock_irq(q->queue_lock);
>> + where = ELEVATOR_INSERT_FLUSH;
>> + goto get_rq;
>
> Is ELEVATOR_INSERT_FRONT not good enough? It seems wrong to use _FLUSH,
> here. If the semantics of ELEVATOR_INSERT_FLUSH are really what is
> required, then perhaps we need to have another think about the naming of
> these flags.
>
Actually - yes, ELEVATOR_INSERT_FRONT would do as well. In the
previous version of MMC stack,
we needed the _FLUSH to trigger the write operation that was to be
preempted, to check that
it actually works.
> Cheers,
> Jeff
>
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists