On 2014/04/25 13:51, Viresh Kumar wrote:
> On 25 April 2014 06:01, Daniel Sangorrin
> wrote:
>>
I can't keep it as a separate patch and so would be required to merge
it into my original patch..
>>>
>>> And the reason being: "No patch is supposed to break things, otherwise
>>> git
On 25 April 2014 06:01, Daniel Sangorrin wrote:
>
>>> I can't keep it as a separate patch and so would be required to merge
>>> it into my original patch..
>>
>> And the reason being: "No patch is supposed to break things, otherwise
>> git bisect wouldn't work smoothly".. And so git bisect would
>> I can't keep it as a separate patch and so would be required to merge
>> it into my original patch..
>
> And the reason being: "No patch is supposed to break things, otherwise
> git bisect wouldn't work smoothly".. And so git bisect would complain
> this issue after my patch and so I have to
On 24 April 2014 14:54, Daniel Sangorrin wrote:
> Why didn't you just apply the patch on top of your tree so that the
> information included in the git commit (e.g: my name and mail) remains?
>
> This part:
>
> cpuset: quiesce: change irq disable/enable by irq save/restore
>
> The function
On 2014/04/24 17:41, Viresh Kumar wrote:
> On 24 April 2014 14:01, Daniel Sangorrin
> wrote:
>> In kernel/cpuset.c:quiesce_cpuset() you are using the function
>> 'smp_call_function_any' which asks CPU cores in 'cpumask' to
>> execute the functions 'hrtimer_quiesce_cpu' and 'timer_quiesce_cpu'.
On 24 April 2014 14:01, Daniel Sangorrin wrote:
> In kernel/cpuset.c:quiesce_cpuset() you are using the function
> 'smp_call_function_any' which asks CPU cores in 'cpumask' to
> execute the functions 'hrtimer_quiesce_cpu' and 'timer_quiesce_cpu'.
>
> In the case above, 'cpumask' corresponds to
On 2014/04/24 16:43, Viresh Kumar wrote:
> On 24 April 2014 12:55, Daniel Sangorrin
> wrote:
>> I tried your set of patches for isolating particular CPU cores from unpinned
>> timers. On x86_64 they were working fine, however I found out that on ARM
>> they would fail under the following test:
Dear Viresh Kumar,
I tried your set of patches for isolating particular CPU cores from unpinned
timers. On x86_64 they were working fine, however I found out that on ARM
they would fail under the following test:
# mount -t cpuset none /cpuset
# cd /cpuset
# mkdir rt
# cd rt
# echo 1 > cpus
#
On 24 April 2014 12:55, Daniel Sangorrin wrote:
> I tried your set of patches for isolating particular CPU cores from unpinned
> timers. On x86_64 they were working fine, however I found out that on ARM
> they would fail under the following test:
I am happy that these drew attention from
On 24 April 2014 12:55, Daniel Sangorrin daniel.sangor...@toshiba.co.jp wrote:
I tried your set of patches for isolating particular CPU cores from unpinned
timers. On x86_64 they were working fine, however I found out that on ARM
they would fail under the following test:
I am happy that these
Dear Viresh Kumar,
I tried your set of patches for isolating particular CPU cores from unpinned
timers. On x86_64 they were working fine, however I found out that on ARM
they would fail under the following test:
# mount -t cpuset none /cpuset
# cd /cpuset
# mkdir rt
# cd rt
# echo 1 cpus
# echo
On 2014/04/24 16:43, Viresh Kumar wrote:
On 24 April 2014 12:55, Daniel Sangorrin daniel.sangor...@toshiba.co.jp
wrote:
I tried your set of patches for isolating particular CPU cores from unpinned
timers. On x86_64 they were working fine, however I found out that on ARM
they would fail
On 24 April 2014 14:01, Daniel Sangorrin daniel.sangor...@toshiba.co.jp wrote:
In kernel/cpuset.c:quiesce_cpuset() you are using the function
'smp_call_function_any' which asks CPU cores in 'cpumask' to
execute the functions 'hrtimer_quiesce_cpu' and 'timer_quiesce_cpu'.
In the case above,
On 2014/04/24 17:41, Viresh Kumar wrote:
On 24 April 2014 14:01, Daniel Sangorrin daniel.sangor...@toshiba.co.jp
wrote:
In kernel/cpuset.c:quiesce_cpuset() you are using the function
'smp_call_function_any' which asks CPU cores in 'cpumask' to
execute the functions 'hrtimer_quiesce_cpu' and
On 24 April 2014 14:54, Daniel Sangorrin daniel.sangor...@toshiba.co.jp wrote:
Why didn't you just apply the patch on top of your tree so that the
information included in the git commit (e.g: my name and mail) remains?
This part:
cpuset: quiesce: change irq disable/enable by irq save/restore
I can't keep it as a separate patch and so would be required to merge
it into my original patch..
And the reason being: No patch is supposed to break things, otherwise
git bisect wouldn't work smoothly.. And so git bisect would complain
this issue after my patch and so I have to merge the
On 25 April 2014 06:01, Daniel Sangorrin daniel.sangor...@toshiba.co.jp wrote:
I can't keep it as a separate patch and so would be required to merge
it into my original patch..
And the reason being: No patch is supposed to break things, otherwise
git bisect wouldn't work smoothly.. And so
On 2014/04/25 13:51, Viresh Kumar wrote:
On 25 April 2014 06:01, Daniel Sangorrin daniel.sangor...@toshiba.co.jp
wrote:
I can't keep it as a separate patch and so would be required to merge
it into my original patch..
And the reason being: No patch is supposed to break things, otherwise
For networking platforms we need to provide one isolated CPU per user space data
plane thread. These CPUs should not be interrupted by kernel at all unless
userspace has requested for some syscalls. And so must live in isolated mode.
Currently, there are background kernel activities that are
For networking platforms we need to provide one isolated CPU per user space data
plane thread. These CPUs should not be interrupted by kernel at all unless
userspace has requested for some syscalls. And so must live in isolated mode.
Currently, there are background kernel activities that are
20 matches
Mail list logo
