From: Grigori Goronzy <greg@chown.ath.cx>
To: "Christian König" <deathsimple@vodafone.de>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/radeon: adjust default radeon_vm_block_size
Date: Sat, 19 Jul 2014 14:37:22 +0200 [thread overview]
Message-ID: <53CA6682.7000005@chown.ath.cx> (raw)
In-Reply-To: <53CA5D0D.7060003@vodafone.de>
[-- Attachment #1.1: Type: text/plain, Size: 4171 bytes --]
On 19.07.2014 13:57, Christian König wrote:
> Yeah, I'm still playing a bit with this.
>
> You need to consider the page directory size as well. If we have 4GB
> address space (32bits) and 12bits in the page, 12bits in the page tables
> then there are only 8bits for the page directory, right?
>
> Now 8bits for the page directory means we have 256 entries with 8bytes
> for each entry that makes 2048 bytes for the page directory. But since
> we allocate 4096 bytes for the page directory anyway we could support
> 8GB address space as well.
>
Yes, that's right... good idea. Larger VM space should also help a bit
with fragmentation under memory pressure, right?
> How about the v2 I've just send out to the list? It also adjusts the
> vm_size to a default of 8GB and let you get vm_block_sizes according to
> the following table:
>
Looks good, I think.
> vm_size vm_block_size
> 1GB = 9
> 2GB = 10
> 4GB = 11
> 8GB = 12
> 16GB = 12
> 32GB = 13
> 64GB = 13
> 128GB = 14
> 256GB = 14
> 512GB = 15
> 1TB = 15
>
> Regards,
> Christian.
>
> Am 18.07.2014 22:03, schrieb Grigori Goronzy:
>> On 18.07.2014 11:38, Christian König wrote:
>>> From: Christian König <christian.koenig@amd.com>
>>>
>>> Signed-off-by: Christian König <christian.koenig@amd.com>
>>> ---
>>> drivers/gpu/drm/radeon/radeon_device.c | 6 +++++-
>>> drivers/gpu/drm/radeon/radeon_drv.c | 4 ++--
>>> 2 files changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>>> b/drivers/gpu/drm/radeon/radeon_device.c
>>> index 03686fa..a2960db 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>>> @@ -1077,7 +1077,11 @@ static void radeon_check_arguments(struct
>>> radeon_device *rdev)
>>> /* defines number of bits in page table versus page directory,
>>> * a page is 4KB so we have 12 bits offset, minimum 9 bits in the
>>> * page table and the remaining bits are in the page directory */
>>> - if (radeon_vm_block_size < 9) {
>>> + if (radeon_vm_block_size == -1) {
>>> + radeon_vm_block_size = (ilog2(radeon_vm_size) + 10) / 2;
>>> + radeon_vm_block_size = max(radeon_vm_block_size, 9);
>>> +
>>> + } else if (radeon_vm_block_size < 9) {
>> Hm, that automatic calculation seems strange. Is there any particular
>> reason why you haven chosen this? This will use vm_block_size=11 for
>> 4096 MB VM space. I have used vm_block_size=12 with good results. This
>> manages 16 MB of VM space per page table, which seems reasonable. I also
>> see a noticeable CPU overhead reduction between 11 and 12.
>>
>> Grigori
>>
>>> dev_warn(rdev->dev, "VM page table size (%d) to small\n",
>>> radeon_vm_block_size);
>>> radeon_vm_block_size = 9;
>>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
>>> b/drivers/gpu/drm/radeon/radeon_drv.c
>>> index cb14213..fef5320 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>>> @@ -174,7 +174,7 @@ int radeon_aspm = -1;
>>> int radeon_runtime_pm = -1;
>>> int radeon_hard_reset = 0;
>>> int radeon_vm_size = 4096;
>>> -int radeon_vm_block_size = 9;
>>> +int radeon_vm_block_size = -1;
>>> int radeon_deep_color = 0;
>>> MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch
>>> registers");
>>> @@ -246,7 +246,7 @@ module_param_named(hard_reset, radeon_hard_reset,
>>> int, 0444);
>>> MODULE_PARM_DESC(vm_size, "VM address space size in megabytes
>>> (default 4GB)");
>>> module_param_named(vm_size, radeon_vm_size, int, 0444);
>>> -MODULE_PARM_DESC(vm_block_size, "VM page table size in bits
>>> (default 9)");
>>> +MODULE_PARM_DESC(vm_block_size, "VM page table size in bits (default
>>> depending on vm_size)");
>>> module_param_named(vm_block_size, radeon_vm_block_size, int, 0444);
>>> MODULE_PARM_DESC(deep_color, "Deep Color support (1 = enable, 0 =
>>> disable (default))");
>>>
>>
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 246 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-07-19 12:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-18 9:38 [PATCH] drm/radeon: adjust default radeon_vm_block_size Christian König
2014-07-18 19:42 ` Alex Deucher
2014-07-18 20:03 ` Grigori Goronzy
2014-07-19 11:57 ` Christian König
2014-07-19 12:37 ` Grigori Goronzy [this message]
2014-07-21 8:10 ` Christian König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53CA6682.7000005@chown.ath.cx \
--to=greg@chown.ath.cx \
--cc=deathsimple@vodafone.de \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox