Re: [PATCH] RFC: mmc: block: replace semaphore with freezing

On Wed, 16 Nov 2016, Rafael J. Wysocki wrote:

quoted

The MMC/SD block core request processing thread is taking a
semaphore in the request processing section and the same
semaphore is taken around suspend/resume operations.

The purpose of the semaphore is to block any request from being
issued to the MMC/SD host controllers when the system is
suspended. A semaphore is used in place of a mutex since the
calls are coming from different threads.

This construction predates the kernel thread freezer mechanism:
we can easily replace the semaphore by instead activating the
freezer with set_freezable() and call try_to_freeze() instead
of the up(); schedule(); down(); construction that is devised
to let the suspend/resume calls get in and grab the semaphore.

Tested with a few suspend/resume to memory cycles on the Ux500
when doing intense dd operations in the background: the
thread thaws and resumes operation after resume.

Well, we had a session at the KS regarding usage of the freezer on
kernel threads and the conclusion was to get rid of that (as opposed
to freezing user space, which is necessary IMO).  So this change would
go in the opposite direction. :-)

[ thanks for CCing me, Rafael ]

Agreed. You already have PM callbacks handled properly, so the way this 
should be done is once you're in the PM-callback due to system going 
through power management change, you just stop generation of any new I/O, 
and tell the kthread that it should schedule itself out.

Plus the schedule() has to stay there anyway, as try_to_freeze() is not 
going to provide you with the schedule() semantics unless the system is 
actually undergoing a PM transition towards suspend.

So either semaphore, or some kind of atomic flag, is exactly the 
information that should be passed from the PM callback to the kthread.

(now, I agree, that this is one of the very rare cases where the kthread 
freezer is actually being used properly -- IOW to pause a kthread that is 
actually generating new I/O ... but given the fact that this is so rare, 
and the API is so heavily abused, I really tend to heavily prefer a 
semaphore / flag based aproach).

Thanks,

-- 
Jiri Kosina
SUSE Labs