Hi Willy
On 7/10/20 4:12 PM, Willy Wolff wrote:
Hi Lukasz,
On 2020-07-08-15-25-03, Lukasz Luba wrote:
Hi Willy,
On 7/3/20 1:33 PM, Willy Wolff wrote:
Hi Chanwoo,
I think it doesn't help on the benchmark I suggested that is doing only memory
accesses. With both timer, I have the same
Hi Lukasz,
On 2020-07-08-15-25-03, Lukasz Luba wrote:
> Hi Willy,
>
> On 7/3/20 1:33 PM, Willy Wolff wrote:
> > Hi Chanwoo,
> >
> > I think it doesn't help on the benchmark I suggested that is doing only
> > memory
> > accesses. With both timer, I have the same timing.
> >
> > To test the
Hi Willy,
On 7/3/20 1:33 PM, Willy Wolff wrote:
Hi Chanwoo,
I think it doesn't help on the benchmark I suggested that is doing only memory
accesses. With both timer, I have the same timing.
To test the benchmark with these new patches about timer:
git clone
Hi all,
On 7/3/20 7:26 AM, Chanwoo Choi wrote:
Add the delayed timer to devfreq framework in order to support
the periodical polling mode without stop caused by CPU idle state.
Some Non-CPU device must need to monitor the device status like
utilization regardless of CPU state.
- patch1
Hi Chanwoo,
On 7/3/20 8:26 AM, Chanwoo Choi wrote:
> Add the delayed timer to devfreq framework in order to support
> the periodical polling mode without stop caused by CPU idle state.
Thank you, this patchset looks fine to me and is a step in the right
direction:
Reviewed-by: Bartlomiej
Hi Chanwoo,
I think it doesn't help on the benchmark I suggested that is doing only memory
accesses. With both timer, I have the same timing.
To test the benchmark with these new patches about timer:
git clone https://github.com/wwilly/benchmark.git \
&& cd benchmark \
&& source env.sh \
6 matches
Mail list logo
