-Original Message-
> 在 2021年04月23日 17:44, HAGIO KAZUHITO(萩尾 一仁) 写道:
> > -Original Message-
> >>> As for the 'write_expire' way, I found that it can be printed after
> >>> "set scope dd_init_queue" or "set scope deadline_init_queue" on old
> >>> kernels.
> >>>
> >>> crash> p write_e
在 2021年04月23日 17:44, HAGIO KAZUHITO(萩尾 一仁) 写道:
> -Original Message-
>>> As for the 'write_expire' way, I found that it can be printed after
>>> "set scope dd_init_queue" or "set scope deadline_init_queue" on old kernels.
>>>
>>> crash> p write_expire
>>> No symbol "write_expire" in current
-Original Message-
> > As for the 'write_expire' way, I found that it can be printed after
> > "set scope dd_init_queue" or "set scope deadline_init_queue" on old kernels.
> >
> > crash> p write_expire
> > No symbol "write_expire" in current context.
> > p: gdb request failed: p write_expir
在 2021年04月23日 15:08, HAGIO KAZUHITO(萩尾 一仁) 写道:
>> -Original Message-
>>> Sure. On my ppc64le machine, crash got 96hz after applying the above patch.
>>> The reason
>>> is that kernel calculates the value of bfq_timeout as below:
>>>
>>> bfq_timeout = HZ / 8;
>>>
>>> The actual value of HZ
在 2021年04月23日 14:41, lijiang 写道:
> 在 2021年04月22日 22:26, lijiang 写道:
>> 在 2021年04月22日 17:33, HAGIO KAZUHITO(萩尾 一仁) 写道:
>>> -Original Message-
-Original Message-
> 在 2021年01月12日 16:24, HAGIO KAZUHITO(萩尾 一仁) 写道:
>> Hi Bhupesh,
>>
>> -Original Message-
>
> -Original Message-
> > Sure. On my ppc64le machine, crash got 96hz after applying the above patch.
> > The reason
> > is that kernel calculates the value of bfq_timeout as below:
> >
> > bfq_timeout = HZ / 8;
> >
> > The actual value of HZ is 100, so bfq_timeout = 100 / 8 = 12, but in cr
在 2021年04月22日 22:26, lijiang 写道:
> 在 2021年04月22日 17:33, HAGIO KAZUHITO(萩尾 一仁) 写道:
>> -Original Message-
>>> -Original Message-
在 2021年01月12日 16:24, HAGIO KAZUHITO(萩尾 一仁) 写道:
> Hi Bhupesh,
>
> -Original Message-
>> We have hard-coded the HZ value for some
在 2021年04月22日 17:33, HAGIO KAZUHITO(萩尾 一仁) 写道:
> -Original Message-
>> -Original Message-
>>> 在 2021年01月12日 16:24, HAGIO KAZUHITO(萩尾 一仁) 写道:
Hi Bhupesh,
-Original Message-
> We have hard-coded the HZ value for some ARCHs to either 1000 or 100
> (mainly
-Original Message-
> -Original Message-
> > 在 2021年01月12日 16:24, HAGIO KAZUHITO(萩尾 一仁) 写道:
> > > Hi Bhupesh,
> > >
> > > -Original Message-
> > >> We have hard-coded the HZ value for some ARCHs to either 1000 or 100
> > >> (mainly for kernel versions > 2.6.0), which causes '
-Original Message-
> 在 2021年01月12日 16:24, HAGIO KAZUHITO(萩尾 一仁) 写道:
> > Hi Bhupesh,
> >
> > -Original Message-
> >> We have hard-coded the HZ value for some ARCHs to either 1000 or 100
> >> (mainly for kernel versions > 2.6.0), which causes 'help -m' to show
> >> an incorrect hz val
在 2021年01月12日 16:24, HAGIO KAZUHITO(萩尾 一仁) 写道:
> Hi Bhupesh,
>
> -Original Message-
>> We have hard-coded the HZ value for some ARCHs to either 1000 or 100
>> (mainly for kernel versions > 2.6.0), which causes 'help -m' to show
>> an incorrect hz value for various architectures.
>
> Good
Hi Bhupesh,
-Original Message-
> We have hard-coded the HZ value for some ARCHs to either 1000 or 100
> (mainly for kernel versions > 2.6.0), which causes 'help -m' to show
> an incorrect hz value for various architectures.
Good catch. but seems crash uses (cfq_slice_async * 25) for mach
We have hard-coded the HZ value for some ARCHs to either 1000 or 100
(mainly for kernel versions > 2.6.0), which causes 'help -m' to show
an incorrect hz value for various architectures.
I tested this on ppc64le and x86_64 and the hz value reported is 1000,
whereas the kernel CONFIG_HZ_100 is set
13 matches
Mail list logo