On Thu, Apr 11, 2013 at 07:10:50AM +0100, Chris Wilson wrote: > On Wed, Apr 10, 2013 at 07:43:39PM -0700, Ben Widawsky wrote: > > I think this is a nice generalization on it's own, but it's primarily > > prep work for my PPGTT support. Does this bother anyone? > > > > The only down side I can see is we waste 2k of cpu unmappable space > > (unless we have something else that is <= 2k and doesn't need to be page > > aligned). > > > > It's RFC because I have only hacked this up and haven't thoroughly > > tested a bunch of error and suspend/resume paths. > > Ugh. Fragmentation, you need a top down allocator. > -Chris
For the current case we can easily address this by setting the range to be the old range and keep the existing allocator but limit it to the same portion it used before. This isn't very interesting though and the previous code is probably better suited for this case anyway since it's inherently much more robust against accidentally overwriting the PDEs. Would you agree that on GEN7 + multiple PPGTTs; the fragmentation is a "don't care"? -- Ben Widawsky, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
