On Monday 19 January 2009, Matthew Wilcox wrote: > > It seems that the PCI code goes out of its way to avoid doing any memory > allocation during the suspend path. For example, there's > pci_allocate_cap_save_buffers() which is called (indirectly) from > pci_device_add(). > > This is a bit of a problem for MSI. I can get the per-interrupt > overhead down to 4 bytes (ie the unsigned int that is the Linux > interrupt number), but if I can't allocate memory during suspend, that > bloats up to 16 bytes per interrupt. The maximum number of interrupts > allocated per devfn is 2048, so that's an extra 24k of ram that either > needs to be allocated all the time, or at suspend time (and then > released at resume time). > > Matthew Garrett tells me there's no reason to avoid memory allocation at > suspend time, indeed it's run twice, once with interrupts on and once > with them off, precisely to permit memory allocations. So why does PCI > try so hard? Is it just an accident of history? AFAICS, it is done so we don't have to allocate memory with interrupts disabled, because that would have to be done with GFP_ATOMIC. pci_allocate_cap_save_buffers() is there exactly for this reason. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
