tracing: document buffer_size_kb more precisely

  buffer_size_kb no longer shows the requested amount, but the one that
is actually used internally for the ring buffer.

commit 6d98a0f2ac3c ("tracing: Set actual size after ring buffer resize")
changed the sysfs behavior such that value read will always show the
actual size, while previously it showed the size that was requested
through the sysfs interface, even if it was rounded up to fulfill
the request.
So the documentation can state that more precisely now.

Signed-off-by: Christian Loehle <christian.loehle@arm.com>
---
 Documentation/trace/ftrace.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

On 2023/9/25 18:02, Christian Loehle wrote:
> buffer_size_kb no longer shows the requested amount, but the one that
> is actually used internally for the ring buffer.
> 
> commit 6d98a0f2ac3c ("tracing: Set actual size after ring buffer resize")
> changed the sysfs behavior such that value read will always show the
> actual size, while previously it showed the size that was requested
> through the sysfs interface, even if it was rounded up to fulfill
> the request.
> So the documentation can state that more precisely now.
> 
> Signed-off-by: Christian Loehle <christian.loehle@arm.com>
> ---
>   Documentation/trace/ftrace.rst | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
> index 23572f6697c0..2e066b3b6edc 100644
> --- a/Documentation/trace/ftrace.rst
> +++ b/Documentation/trace/ftrace.rst
> @@ -191,7 +191,7 @@ of ftrace. Here is a list of some of the key files:
>   	A few extra pages may be allocated to accommodate buffer management
>   	meta-data. If the last page allocated has room for more bytes
>   	than requested, the rest of the page will be used,
> -	making the actual allocation bigger than requested or shown.
> +	making the actual allocation bigger than requested.

Hi, the actual allocation should still be bigger than shown due to the
loss of accuracy when doing unit conversion from bytes to kilobytes (see
tracing_entries_read()).

--

Thanks,
Zheng Yejian

>   	( Note, the size may not be a multiple of the page size
>   	due to buffer management meta-data. )
>
  

On 25/09/2023 12:44, Zheng Yejian wrote:
> On 2023/9/25 18:02, Christian Loehle wrote:
>> buffer_size_kb no longer shows the requested amount, but the one that
>> is actually used internally for the ring buffer.
>>
>> commit 6d98a0f2ac3c ("tracing: Set actual size after ring buffer resize")
>> changed the sysfs behavior such that value read will always show the
>> actual size, while previously it showed the size that was requested
>> through the sysfs interface, even if it was rounded up to fulfill
>> the request.
>> So the documentation can state that more precisely now.
>>
>> Signed-off-by: Christian Loehle <christian.loehle@arm.com>
>> ---
>>   Documentation/trace/ftrace.rst | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
>> index 23572f6697c0..2e066b3b6edc 100644
>> --- a/Documentation/trace/ftrace.rst
>> +++ b/Documentation/trace/ftrace.rst
>> @@ -191,7 +191,7 @@ of ftrace. Here is a list of some of the key files:
>>       A few extra pages may be allocated to accommodate buffer management
>>       meta-data. If the last page allocated has room for more bytes
>>       than requested, the rest of the page will be used,
>> -    making the actual allocation bigger than requested or shown.
>> +    making the actual allocation bigger than requested.
> 
> Hi, the actual allocation should still be bigger than shown due to the
> loss of accuracy when doing unit conversion from bytes to kilobytes (see
> tracing_entries_read()).
> 
Right, the sysfs obviously only allows for KB aligned setting, but you're right.
If set on the cmdline non-KB multiples are possible and accuracy is lost.
Nevermind then.

> -- 
> 
> Thanks,
> Zheng Yejian
> 
>>       ( Note, the size may not be a multiple of the page size
>>       due to buffer management meta-data. )
>>   
>
  

On Tue, 26 Sep 2023 11:38:14 +0100
Christian Loehle <christian.loehle@arm.com> wrote:

> >> @@ -191,7 +191,7 @@ of ftrace. Here is a list of some of the key files:
> >>       A few extra pages may be allocated to accommodate buffer management
> >>       meta-data. If the last page allocated has room for more bytes
> >>       than requested, the rest of the page will be used,
> >> -    making the actual allocation bigger than requested or shown.
> >> +    making the actual allocation bigger than requested.  
> > 
> > Hi, the actual allocation should still be bigger than shown due to the
> > loss of accuracy when doing unit conversion from bytes to kilobytes (see
> > tracing_entries_read()).
> >   
> Right, the sysfs obviously only allows for KB aligned setting, but you're right.
> If set on the cmdline non-KB multiples are possible and accuracy is lost.
> Nevermind then.

I'm assuming this patch can be dropped?

-- Steve
  

On 02/10/2023 16:09, Steven Rostedt wrote:
> On Tue, 26 Sep 2023 11:38:14 +0100
> Christian Loehle <christian.loehle@arm.com> wrote:
> 
>>>> @@ -191,7 +191,7 @@ of ftrace. Here is a list of some of the key files:
>>>>       A few extra pages may be allocated to accommodate buffer management
>>>>       meta-data. If the last page allocated has room for more bytes
>>>>       than requested, the rest of the page will be used,
>>>> -    making the actual allocation bigger than requested or shown.
>>>> +    making the actual allocation bigger than requested.  
>>>
>>> Hi, the actual allocation should still be bigger than shown due to the
>>> loss of accuracy when doing unit conversion from bytes to kilobytes (see
>>> tracing_entries_read()).
>>>   
>> Right, the sysfs obviously only allows for KB aligned setting, but you're right.
>> If set on the cmdline non-KB multiples are possible and accuracy is lost.
>> Nevermind then.
> 
> I'm assuming this patch can be dropped?
> 
> -- Steve
Yes please drop it, there's probably still some room for improvement for clarity,
but this patch is not correct.