[Intel-gfx] [PATCH 15/17] drm/i915: Increase GuC log buffer size to reduce flush interrupts
Goel, Akash
akash.goel at intel.com
Fri Jul 15 14:42:01 UTC 2016
On 7/15/2016 5:27 PM, Tvrtko Ursulin wrote:
>
> On 10/07/16 14:41, akash.goel at intel.com wrote:
>> From: Akash Goel <akash.goel at intel.com>
>>
>> In cases where GuC generate logs at a very high rate, correspondingly
>> the rate of flush interrupts is also very high.
>> So far total 8 pages were allocated for storing both ISR & DPC logs.
>> As per the half-full draining protocol followed by GuC, by doubling
>> the number of pages, the frequency of flush interrupts can be cut down
>> to almost half, which then helps in reducing the logging overhead.
>> So now allocating 8 pages apiece for ISR & DPC logs.
>>
>> Suggested-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
>> Signed-off-by: Akash Goel <akash.goel at intel.com>
>> ---
>> drivers/gpu/drm/i915/intel_guc_fwif.h | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
>> b/drivers/gpu/drm/i915/intel_guc_fwif.h
>> index 1de6928..7521ed5 100644
>> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
>> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
>> @@ -104,9 +104,9 @@
>> #define GUC_LOG_ALLOC_IN_MEGABYTE (1 << 3)
>> #define GUC_LOG_CRASH_PAGES 1
>> #define GUC_LOG_CRASH_SHIFT 4
>> -#define GUC_LOG_DPC_PAGES 3
>> +#define GUC_LOG_DPC_PAGES 7
>> #define GUC_LOG_DPC_SHIFT 6
>> -#define GUC_LOG_ISR_PAGES 3
>> +#define GUC_LOG_ISR_PAGES 7
>> #define GUC_LOG_ISR_SHIFT 9
>> #define GUC_LOG_BUF_ADDR_SHIFT 12
>>
>> @@ -436,9 +436,9 @@ enum guc_log_buffer_type {
>> * | Crash dump state header |
>> * Page1 +-------------------------------+
>> * | ISR logs |
>> - * Page5 +-------------------------------+
>> - * | DPC logs |
>> * Page9 +-------------------------------+
>> + * | DPC logs |
>> + * Page17 +-------------------------------+
>> * | Crash Dump logs |
>> * +-------------------------------+
>> *
>>
>
> I don't mind - but does it help? And how much and for what? Haven't you
> later found that the uncached reads were the main issue?
This change along with kthread patch, helped reduce the overflow counts
and even eliminate them for some benchmarks.
Though with the impending optimization for Uncached reads there should
be further improvements but in my view, notwithstanding the improvement
w.r.t overflow count, its still a better configuration to work with as
flush interrupt frequency is cut down to half and not able to see any
apparent downsides to it.
Best Regards
Akash
>
> Regards,
>
> Tvrtko
More information about the Intel-gfx
mailing list