Vitaly Wool wrote:
David Brownell wrote:
Yeah thus we don't have an ability to allocate SPI messages on stack
as you do, that's what votes for your approach. Yours is thus a bit
faster, though I suspect that this method is a possible *danger* for
really high-speed devices with data bursts on the SPI bus like WiFi
adapters: stack's gonna suffer from large amounts of data allocated.
No, you're still thinking about a purely synchronous programming model;
which we had agreed ages ago was not required.
Ah yes. But wait... I've got an important question here.
For instance, let's take your MTD driver. You're allocating a message
structure on stack and passing it then down to spi->master->transfer
function.
The benefit you're talking about is that you don't have to use
heavyweight memory allocation. But... the transfer is basically async
so spi->master->transfer will need to copy your message structure to
its own-allocated structure so some memory copying will occur as this
might be an async transfer (and therefore the stack-allocated message
may be freed at some point when it's yet used!)
So your model implies concealed double message allocation/copying,
doesn't it?
And if I'm wrong, can you please explain me this?
Oh, now looks like I understood what is meant. If a function uses
stack-allocated messages, it should ensure that it will not exit until
the message is processed (shouldn't it be documented somewhere?). But
this solves the problem only partially since this technique fits only
the synchronous transfers.
Functions targeting async transfers will anyway have to kmalloc the
memory for message structure which makes your approach not really more
lightweight then ours. It's mainly async transfers that need high
throughput; and the drivers based on your core will have to kmalloc
memory for messages in that case.
Vitaly
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
