On Mon, Jan 19, 2009 at 10:45:18AM +0100, Rafael J. Wysocki wrote: > 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. You recently wrote: > > > Nope. pci_prepare_to_sleep() is called during suspend, from > > > pci_pm_default_suspend(), with interrupts on. Why can't we allocate memory in pci_prepare_to_sleep()? -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- 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
