On 17-06-27 04:01 AM, Christian König wrote: > Am 27.06.2017 um 04:57 schrieb Michel Dänzer: >> On 27/06/17 08:39 AM, John Brooks wrote: >>> On Mon, Jun 26, 2017 at 03:39:57PM +0200, Christian König wrote: >>>> From: Christian König <christian.koenig at amd.com> >>>> >>>> Limit the size of the GART table for the system domain. >>>> >>>> This saves us a bunch of visible VRAM, but also limitates the >>>> maximum BO size we can swap out. >>>> >>>> Signed-off-by: Christian König <christian.koenig at amd.com> >>> Hmm. >>> >>> On my system, GTT is 4096MiB (1048576 pages). For this, the table >>> takes up >>> 1048576*8 bytes = 8MiB. Reducing GTT to 256MiB (65536 pages) would >>> reduce the >>> size of the table to 512 KiB. A relatively large saving, to be sure. >>> But in the >>> grander scheme of things, is saving 7.5MiB (3% of visible VRAM @ >>> 256M) worth >>> cutting GTT memory by a factor of 16? > > The amount of GTT memory the application can use through the VM page > tables stays the same. > > Only the system VM is limited to 256MB and so saves us a whole bunch > of space. > >> I'm afraid not, especially since it would limit the maximum BO size to < >> 256MB, if I understand correctly. Pretty sure that would cause failures >> with real world apps. > Yes, exactly that's the major problem here. I should have put a WIP > mark on the patch. OK, I should adapt this for the KFD branch. Currently we make our GART much bigger. On a system with lots of system memory, we can use up half the visible VRAM for the GART. With something like this we can get it back to something reasonable. But a 256MB limit on single allocation size is definitely too small. Also, if this breaks S3, we have to make sure the hybrid branches don't pick it up accidentally. Regards, Felix > > Christian.
