[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1493702784.23202.64.camel@haakon3.risingtidesystems.com>
Date: Mon, 01 May 2017 22:26:24 -0700
From: "Nicholas A. Bellinger" <nab@...ux-iscsi.org>
To: Mike Christie <mchristi@...hat.com>
Cc: Xiubo Li <lixiubo@...s.chinamobile.com>, agrover@...hat.com,
iliastsi@...ikto.com, namei.unix@...il.com, sheng@...ker.org,
linux-scsi@...r.kernel.org, target-devel@...r.kernel.org,
linux-kernel@...r.kernel.org,
Jianfei Hu <hujianfei@...s.chinamobile.com>
Subject: Re: [PATCH v6 2/2] tcmu: Add global data block pool support
On Mon, 2017-05-01 at 13:40 -0500, Mike Christie wrote:
> On 04/30/2017 06:29 AM, Xiubo Li wrote:
> > [...]
<SNIP>
> >> To avoid starvation, I think you want a second list/fifo that holds the
> >> watiers. In tcmu_get_empty_block if the list is not empty, record how
> >> many pages we needed and then add the device to the list and wait in
> >> tcmu_queue_cmd_ring.
> >>
> >> Above if we freed enough pages for the device at head then wake up the
> >> device.
> >>
> >> I think you also need a wake_up call in the completion path in case the
> >> initial call could not free enough pages. It could probably check if the
> >> completion was going to free enough pages for a waiter and then call
> >> wake.
> >>
> > Yes, I meant to introduce this later after this series to not let the
> > patches too
> > complex to review.
> >
> > If you agree I will do this later, or in V7 series ?
>
>
> Yeah, I am ok with adding it after the initial patches go in.
Btw, adding your Acked-by for the initial merge of these.
If that's a problem, please make some noise. ;)
Powered by blists - more mailing lists