[lkml]   [2018]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: blktest for [PATCH v2] block: do not use interruptible wait anywhere
On 14/04/18 20:52, Jens Axboe wrote:
> On 4/14/18 1:46 PM, Alan Jenkins wrote:
>> On 13/04/18 09:31, Johannes Thumshirn wrote:
>>> Hi Alan,
>>> On Thu, 2018-04-12 at 19:11 +0100, Alan Jenkins wrote:
>>>> # dd if=/dev/sda of=/dev/null iflag=direct & \
>>>> while killall -SIGUSR1 dd; do sleep 0.1; done & \
>>>> echo mem > /sys/power/state ; \
>>>> sleep 5; killall dd # stop after 5 seconds
>>> Can you please also add a regression test to blktests[1] for this?
>>> [1]
>>> Thanks,
>>> Johannes
>> Good question. It would be nice to promote this test.
>> Template looks like I need the commit (sha1) first.
>> I had some ideas about automating it, so I wrote a standalone (see
>> end).  I can automate the wakeup by using pm_test, but this is still a
>> system suspend test.  Unfortunately I don't think there's any
>> alternative. To give the most dire example
>> # This test is non-destructive, but it exercises suspend in all drivers.
>> # If your system has a problem with suspend, it might not wake up again.
>> So I'm not sure if it would be acceptable for the default set?
>> How useful is this going to be? Is there an expanded/full set of tests
>> that gets run somewhere?
>> If you can't guarantee it's going to be run somewhere, I'd worry the
>> cost/benefit  feels a little narrow :-(. There were one or two further
>> "interesting" details, and it might theoretically bitrot if it's not run
>> periodically.
> I run it, just last week we found two new bugs with it. I'm requiring
> anyone that submits block patches to run the test suite, and also
> working towards having it be part of the 0-day runs so it gets run
> on posted patches automatically.
> So yes, it's useful and it won't bitrot. Please do turn it into a blktests
> test.

Thanks, it's really great to have a test suite. I was specifically
checking in on how we can include a system suspend test.

I've been thinking the suspend test could be opt-in test (e.g.
ALLOW_PM_TEST=1), and then we have some infrastructure (you or 0-day
runs) that does the opt-in.  Without knowing anything about the
infrastructure, I didn't want to assume that would work.

I'm aware of one particular suspend issue; inside virt-manager VMs I see
Linux crashing with a null pointer in qxl_drm_freeze.  A regression soon
after I learned how to use VMs for suspend tests :-( , and it's been
long enough that I suspect few people use it.

Partly what you saw me fishing for in the comments, is the idea of some
kernel code allowing more direct testing of the queue freeze /
preempt_only flag.  That might be better engineering, but I don't know
where I could put it.


 \ /
  Last update: 2018-04-15 14:16    [W:0.035 / U:10.576 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site