Re: [PATCH] IB/fmr_pool: Convert the cleanup thread into kthread worker API

[Petr Mladek]

On Tue 2017-04-25 14:29:48, Doug Ledford wrote:
> On Mon, 2016-10-17 at 17:39 +0200, Petr Mladek wrote:
> > Kthreads are currently implemented as an infinite loop. Each
> > has its own variant of checks for terminating, freezing,
> > awakening. In many cases it is unclear to say in which state
> > it is and sometimes it is done a wrong way.
> > 
> > The plan is to convert kthreads into kthread_worker or workqueues
> > API. It allows to split the functionality into separate operations.
> > It helps to make a better structure. Also it defines a clean state
> > where no locks are taken, IRQs blocked, the kthread might sleep
> > or even be safely migrated.
> > 
> > The kthread worker API is useful when we want to have a dedicated
> > single thread for the work. It helps to make sure that it is
> > available when needed. Also it allows a better control, e.g.
> > define a scheduling priority.
> > 
> > This patch converts the frm_pool kthread into the kthread worker
> > API because I am not sure how busy the thread is. It is well
> > possible that it does not need a dedicated kthread and workqueues
> > would be perfectly fine. Well, the conversion between kthread
> > worker API and workqueues is pretty trivial.
> > 
> > The patch moves one iteration from the kthread into the work
> > function.
> > It is queued only when there is a pending work. Therefore we do not
> > need to compare flush_ser and req_ser at the beginning. On the
> > contrary,
> > the same work could be queued only once at a time. Therefore it has
> > to
> > re-queue itself if some requests are pending.
> > 
> > Otherwise, wake_up_process() is replaced by queuing the work.
> > 
> > Important: The change is only compile tested. I did not find an easy
> > way how to check it in a real life.
> > 
> > Signed-off-by: Petr Mladek <pmladek@xxxxxxxx>
> > TO: Doug Ledford <dledford@xxxxxxxxxx>
> > CC: Sean Hefty <sean.hefty@xxxxxxxxx>
> > CC: Hal Rosenstock <hal.rosenstock@xxxxxxxxx>
> > CC: linux-rdma@xxxxxxxxxxxxxxx
> 
> Hi Petr,
> 
> This patch has sat around for a long time.  I've decided to take it in
> this release, even though it isn't really tested, on the basis that we
> will perform some testing internally using the mthca driver (if you
> combine the mthca driver with certain upper level protocols, you can
> create a situation where FMR memory will be the preferred memory in use
> IIRC) and revert if it doesn't work properly.

Thanks a lot for taking it. I hope that it will be fine.

Best Regards,
Petr