On Saturday 17 December 2005 1:18 pm, Vitaly Wool wrote:Can't get what you're talking about. A freelist of what?
Greetings,
the patch attached changes the way transfers are chained in the SPI core. Namely, they are turned into linked lists instead of array. The reason behind is that we'd like to be able to use lightweight memory allocation mechanism to use it in interrupt context.
Hmm, color me confused. Is there something preventing a driver from
having its own freelist (or whatever), in cases where kmalloc doesn't
suffice? If not, why should the core change? And what sort of driver
measurements are you doing, to conclude that kmalloc doesn't suffice?
Disagree. Let's look deeper. kmalloc itself is more heavyweght than setting up list memberships.
An example of such kind of mechanism can be found in spi-alloc.c file in our core. The lightweightness is achieved by the knowledge that all the blocks to be allocated are of the same size.
I'd have said that since this increases the per-transfer costs (to set
up and manage the list memberships) you want to increase the weight of
that part of the API, not decrease it. ;)
Note that your current API maps to mine roughly by equatingThis is the patch to your API, so I don't see why you're mentioning it here.
allocate your spi_msg allocate my { spi_message + one spi_transfer }
So if you're doing one allocation anyway, you already have the relevant
linked list (in spi_message) and pre-known size. So this patch wouldn't
improve any direct translation of your driver stack.
The problem is: we're using real-time enhancements patch developed by Ingo/Sven/Daniel etc. You cannot call kmalloc from the interrupt context if you're using this patch. Yeah, yeah -- the interrupt handlers are in threads by default, but we can't go for that since we want immediate acknowledgement from the interrupt context, and that implies spi_message/spi_transfer allocation.We'd like to use this allocation technique for both message structure and transfer structure The problem with the current code is that transfers are represnted as an array so it can be of any size effectively.
Could you elaborate on this problem you perceive? This isn't the only
driver API in Linux to talk in terms of arrays describing transfers,
even potentially large arrays.
Consider how "struct scatterlist" is used, and how USB manages theNot sure if I understand why it's relevant to what we're discussing.
descriptors for isochronous transfers. They don't use linked lists
there, and haven't seemed to suffer from it.