Unexpected scheduling with mutexes

[Martin Christian]

Thanks a lot for the detailed reply!

>> For certain values of `X` there is a significant difference in size
>> between the two files, which I don't expect.
>>
>> A read call to the driver does the following:
>>  1. `mutex_lock_interruptible(iolock)`
>>  2. `usb_bulk_msg(dev, pipe, buf, X, timeout)`
>>  3. `mutex_unlock(iolock)`
>>  4. `copy_to_user(buf)`
> 
> What are these values of X that cause differences here?

Starting around 1k character device A gets more data until it turns over
at around 4K. Request size from 10K yield the expected data rates.

Character device A is a "real" random source and returns data much
slower than device B, which is a pseudo random source.

> But if you are trying to somehow create a real api that you have to
> enforce the passing off of writing data from two different character
> devices in an interleaved format, you are doing this totally wrong, as
> this is not going to work with a simple mutex, as you have found out.

As mentioned above, the USB device provides two different streams of
random. But the device can process only one request at a time. Also I
didn't want to have too much dynamic memory allocation, because I would
need to allocate up to 64KB kernel memory on each open.

That's because the USB device is designed to provide up to 64K of random
in a single "request". A request has a header and footer "protecting"
the request as a whole from data confusion.

To make things simpler I decided to just allow one user space process at
a time for each source - which is enough for our application. But yes,
that could probably also got to user space.

> So, I really haven't answered your question here except to say, "it's
> complicated" and "you aren't measuring what you think you are measuring" :)

Ok, I see.

Thanks,

Martin Christian

-- 
Dipl.-Inf. Martin Christian
Senior Berater Entwicklung Hardware
secunet Security Networks AG

Tel.: +49 201 5454-3612, Fax +49 201 5454-1323
E-Mail: martin.christian at secunet.com
Ammonstraße 74, 01067 Dresden
www.secunet.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20190403/c36fad72/attachment.sig>