I think the prime issue is that dma_direct_alloc respects the dma
mask. Which we don't need if actually using the iommu. This would
be mostly harmless exept for the the SEV bit high in the address that
makes the checks fail.
For now I'd say revert this commit for 4.17/4.18-rc and I'll look into
I think the prime issue is that dma_direct_alloc respects the dma
mask. Which we don't need if actually using the iommu. This would
be mostly harmless exept for the the SEV bit high in the address that
makes the checks fail.
For now I'd say revert this commit for 4.17/4.18-rc and I'll look into
Am 06.06.2018 um 16:12 schrieb Michel Dänzer:
On 2018-06-06 03:33 PM, Gabriel C wrote:
2018-06-06 14:19 GMT+02:00 Christian König :
Am 06.06.2018 um 14:08 schrieb Gabriel C:
2018-06-06 13:33 GMT+02:00 Christian König :
Am 06.06.2018 um 13:28 schrieb Gabriel C:
2018-04-11 7:02 GMT+02:00
Am 06.06.2018 um 16:12 schrieb Michel Dänzer:
On 2018-06-06 03:33 PM, Gabriel C wrote:
2018-06-06 14:19 GMT+02:00 Christian König :
Am 06.06.2018 um 14:08 schrieb Gabriel C:
2018-06-06 13:33 GMT+02:00 Christian König :
Am 06.06.2018 um 13:28 schrieb Gabriel C:
2018-04-11 7:02 GMT+02:00
Am 06.06.2018 um 14:08 schrieb Gabriel C:
2018-06-06 13:33 GMT+02:00 Christian König :
Am 06.06.2018 um 13:28 schrieb Gabriel C:
2018-04-11 7:02 GMT+02:00 Gabriel C :
2018-04-11 6:00 GMT+02:00 Gabriel C :
2018-04-09 11:42 GMT+02:00 Christian König
:
Am 07.04.2018 um 00:00 schrieb Jean-Marc
Am 06.06.2018 um 14:08 schrieb Gabriel C:
2018-06-06 13:33 GMT+02:00 Christian König :
Am 06.06.2018 um 13:28 schrieb Gabriel C:
2018-04-11 7:02 GMT+02:00 Gabriel C :
2018-04-11 6:00 GMT+02:00 Gabriel C :
2018-04-09 11:42 GMT+02:00 Christian König
:
Am 07.04.2018 um 00:00 schrieb Jean-Marc
On 2018-04-20 09:40 PM, Felix Kuehling wrote:
> On 2018-04-20 10:47 AM, Michel Dänzer wrote:
>> On 2018-04-11 11:37 AM, Christian König wrote:
>>> Am 11.04.2018 um 06:00 schrieb Gabriel C:
2018-04-09 11:42 GMT+02:00 Christian König
:
> Am 07.04.2018
On 2018-04-20 09:40 PM, Felix Kuehling wrote:
> On 2018-04-20 10:47 AM, Michel Dänzer wrote:
>> On 2018-04-11 11:37 AM, Christian König wrote:
>>> Am 11.04.2018 um 06:00 schrieb Gabriel C:
2018-04-09 11:42 GMT+02:00 Christian König
:
> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
[+Philip]
On 2018-04-20 10:47 AM, Michel Dänzer wrote:
> On 2018-04-11 11:37 AM, Christian König wrote:
>> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>>> 2018-04-09 11:42 GMT+02:00 Christian König
>>> :
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
> Hi
[+Philip]
On 2018-04-20 10:47 AM, Michel Dänzer wrote:
> On 2018-04-11 11:37 AM, Christian König wrote:
>> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>>> 2018-04-09 11:42 GMT+02:00 Christian König
>>> :
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
> Hi Christian,
>
> Thanks for
On 2018-04-11 11:37 AM, Christian König wrote:
> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>> 2018-04-09 11:42 GMT+02:00 Christian König
>> :
>>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also
On 2018-04-11 11:37 AM, Christian König wrote:
> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>> 2018-04-09 11:42 GMT+02:00 Christian König
>> :
>>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
2018-04-12 0:20 GMT+02:00 Gabriel C :
> 2018-04-11 20:35 GMT+02:00 Jean-Marc Valin :
>> On 04/11/2018 05:37 AM, Christian König wrote:
With your patches my EPYC box is unusable with 4.15++ kernels.
The whole Desktop is acting weird. This one
2018-04-12 0:20 GMT+02:00 Gabriel C :
> 2018-04-11 20:35 GMT+02:00 Jean-Marc Valin :
>> On 04/11/2018 05:37 AM, Christian König wrote:
With your patches my EPYC box is unusable with 4.15++ kernels.
The whole Desktop is acting weird. This one is using
an Cape Verde PRO [Radeon HD
2018-04-11 20:35 GMT+02:00 Jean-Marc Valin :
> On 04/11/2018 05:37 AM, Christian König wrote:
>>> With your patches my EPYC box is unusable with 4.15++ kernels.
>>> The whole Desktop is acting weird. This one is using
>>> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E]
2018-04-11 20:35 GMT+02:00 Jean-Marc Valin :
> On 04/11/2018 05:37 AM, Christian König wrote:
>>> With your patches my EPYC box is unusable with 4.15++ kernels.
>>> The whole Desktop is acting weird. This one is using
>>> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU.
>>>
>>> Box is 2 *
On 04/11/2018 05:37 AM, Christian König wrote:
>> With your patches my EPYC box is unusable with 4.15++ kernels.
>> The whole Desktop is acting weird. This one is using
>> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU.
>>
>> Box is 2 * EPYC 7281 with 128 GB ECC RAM
>>
>> Also a 14C Xeon
On 04/11/2018 05:37 AM, Christian König wrote:
>> With your patches my EPYC box is unusable with 4.15++ kernels.
>> The whole Desktop is acting weird. This one is using
>> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU.
>>
>> Box is 2 * EPYC 7281 with 128 GB ECC RAM
>>
>> Also a 14C Xeon
2018-04-11 16:26 GMT+02:00 Gabriel C :
> 2018-04-11 11:37 GMT+02:00 Christian König :
>> Am 11.04.2018 um 06:00 schrieb Gabriel C:
...
>>
>> Please test Alex's amd-staging-drm-next branch from
>> git://people.freedesktop.org/~agd5f/linux.
>
> I'm on
2018-04-11 16:26 GMT+02:00 Gabriel C :
> 2018-04-11 11:37 GMT+02:00 Christian König :
>> Am 11.04.2018 um 06:00 schrieb Gabriel C:
...
>>
>> Please test Alex's amd-staging-drm-next branch from
>> git://people.freedesktop.org/~agd5f/linux.
>
> I'm on it just the connection to freedesktop.org is
2018-04-11 11:37 GMT+02:00 Christian König :
> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>>
>> 2018-04-09 11:42 GMT+02:00 Christian König
>> :
>>>
>>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
2018-04-11 11:37 GMT+02:00 Christian König :
> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>>
>> 2018-04-09 11:42 GMT+02:00 Christian König
>> :
>>>
>>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that
Am 11.04.2018 um 06:00 schrieb Gabriel C:
2018-04-09 11:42 GMT+02:00 Christian König :
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
Am 11.04.2018 um 06:00 schrieb Gabriel C:
2018-04-09 11:42 GMT+02:00 Christian König :
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment
>2018-04-11 6:00 GMT+02:00 Gabriel C :
> 2018-04-09 11:42 GMT+02:00 Christian König :
>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
...
> I can help testing code for 4.17/++ if you wish but that is *different*
> storry.
>
Quick tested
>2018-04-11 6:00 GMT+02:00 Gabriel C :
> 2018-04-09 11:42 GMT+02:00 Christian König :
>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
...
> I can help testing code for 4.17/++ if you wish but that is *different*
> storry.
>
Quick tested an 4.16.0-11490-gb284d4d5a678 , amdgpu and radeon driver
2018-04-09 11:42 GMT+02:00 Christian König :
> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
>>
>> Hi Christian,
>>
>> Thanks for the info. FYI, I've also opened a Firefox bug for that at:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
>> Feel free to
2018-04-09 11:42 GMT+02:00 Christian König :
> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
>>
>> Hi Christian,
>>
>> Thanks for the info. FYI, I've also opened a Firefox bug for that at:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
>> Feel free to comment since you have a better
Am 09.04.2018 um 17:17 schrieb Jean-Marc Valin:
On 04/09/2018 05:42 AM, Christian König wrote:
Backporting all the detection logic is to invasive, but you could just
go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the
other code path.
Just look out for "#ifdef CONFIG_SWIOTLB"
Am 09.04.2018 um 17:17 schrieb Jean-Marc Valin:
On 04/09/2018 05:42 AM, Christian König wrote:
Backporting all the detection logic is to invasive, but you could just
go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the
other code path.
Just look out for "#ifdef CONFIG_SWIOTLB"
On 04/09/2018 05:42 AM, Christian König wrote:
> Backporting all the detection logic is to invasive, but you could just
> go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the
> other code path.
>
> Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those.
Do you mean
On 04/09/2018 05:42 AM, Christian König wrote:
> Backporting all the detection logic is to invasive, but you could just
> go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the
> other code path.
>
> Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those.
Do you mean
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment since you have a better understanding of what's
going on.
One last question: right now
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment since you have a better understanding of what's
going on.
One last question: right now
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment since you have a better understanding of what's
going on.
One last question: right now I'm running 4.15.0 with the "offending"
patch
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment since you have a better understanding of what's
going on.
One last question: right now I'm running 4.15.0 with the "offending"
patch
Am 06.04.2018 um 18:42 schrieb Jean-Marc Valin:
Hi Christian,
On 04/09/2018 07:48 AM, Christian König wrote:
Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time?
Only at compile time by not setting
Am 06.04.2018 um 18:42 schrieb Jean-Marc Valin:
Hi Christian,
On 04/09/2018 07:48 AM, Christian König wrote:
Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time?
Only at compile time by not setting
Hi Christian,
On 04/09/2018 07:48 AM, Christian König wrote:
> Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
>> Hi Christian,
>>
>> Is there a way to turn off these huge pages at boot-time/run-time?
>
> Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.
Any reason why
echo never
Hi Christian,
On 04/09/2018 07:48 AM, Christian König wrote:
> Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
>> Hi Christian,
>>
>> Is there a way to turn off these huge pages at boot-time/run-time?
>
> Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.
Any reason why
echo never
Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time?
Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.
Alternatively you can avoid enabling CONFIG_SWIOTLB which will avoid the
slow DMA path as well.
Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time?
Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.
Alternatively you can avoid enabling CONFIG_SWIOTLB which will avoid the
slow DMA path as well.
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time? Right
now the recent kernels are making Firefox pretty much unusable for me.
I've been able to revert the patch from 4.15 but it's not really a
long-term solution.
You mention that the purpose of the patch is to
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time? Right
now the recent kernels are making Firefox pretty much unusable for me.
I've been able to revert the patch from 4.15 but it's not really a
long-term solution.
You mention that the purpose of the patch is to
Hi Jean,
found the bug reports.
Here is the original bug report from the kernel:
https://bugzilla.kernel.org/show_bug.cgi?id=198511
And here is an fdo bug report where we tried to investigate the root
cause, but didn't had time for that yet:
Hi Jean,
found the bug reports.
Here is the original bug report from the kernel:
https://bugzilla.kernel.org/show_bug.cgi?id=198511
And here is an fdo bug report where we tried to investigate the root
cause, but didn't had time for that yet:
Hi Jean,
yeah, that is a known problem. Using huge pages improves the performance
because of better TLB usage, but for the cost of higher allocation overhead.
What we found is that firefox is doing something rather strange by
allocating large textures and then just trowing them away again
Hi Jean,
yeah, that is a known problem. Using huge pages improves the performance
because of better TLB usage, but for the cost of higher allocation overhead.
What we found is that firefox is doing something rather strange by
allocating large textures and then just trowing them away again
Hi,
I noticed a serious graphics performance regression between 4.14 and
4.15. It is most noticeable with Firefox (tried FF57 through FF60) and
causes scrolling to be really choppy/sluggish. I've confirmed that the
problem is also there on 4.16, while 4.13 works fine.
After a bisection, I've
Hi,
I noticed a serious graphics performance regression between 4.14 and
4.15. It is most noticeable with Firefox (tried FF57 through FF60) and
causes scrolling to be really choppy/sluggish. I've confirmed that the
problem is also there on 4.16, while 4.13 works fine.
After a bisection, I've
50 matches
Mail list logo