> The onstack array seems fine to me, even if you do end up deciding on > an array of one. Is there any evidence that it's a problem getting a > page for the freeing (other than in circumstances that are already > badly slowed down)? It's obvious that we need a fallback route, > but optimizing throughput on that route seems premature.
Hrm, no evidence of that so far indeed. I'm worried by the stack usage of the unmap_mapping_ranges() but appart from that, no. Appart from that, yeah, I suppose we can have a macro defining how many on-stack backup we have and adjust it if we see that being a problem. I'm not fan of dynamic on-stack allocations. Ben. - 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/