Unexpected scheduling with mutexes
martin.christian at secunet.com
Wed Apr 3 05:33:56 EDT 2019
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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Kernelnewbies