Hi Viresh,
On 04/22/2014 03:32 AM, Viresh Kumar wrote:
> On Thu, Oct 3, 2013 at 11:10 PM, Christoph Lameter wrote:
>> V2->V3:
>> - Introduce a new tick_get_housekeeping_cpu() function. Not sure
>> if that is exactly what we want but it is a start. Thomas?
>> - Migrate the shepherd task if the
Hi Viresh,
On 04/22/2014 03:32 AM, Viresh Kumar wrote:
On Thu, Oct 3, 2013 at 11:10 PM, Christoph Lameter c...@linux.com wrote:
V2-V3:
- Introduce a new tick_get_housekeeping_cpu() function. Not sure
if that is exactly what we want but it is a start. Thomas?
- Migrate the shepherd task if
On 01/05/2013 02:16 AM, Toralf Förster wrote:
> At my stable Gentoo Linux I'm observed a change behaviour for the
> configured TAP devices after the boot process.
>
> $ diff 3.7.1 3.8.0-rc1+ | grep UP
>- br0: flags=4355 mtu 1500
>+ br0: flags=4419 mtu 1500
>- tap0: flags=4099 mtu 1500
>+ tap0:
On 01/05/2013 02:16 AM, Toralf Förster wrote:
At my stable Gentoo Linux I'm observed a change behaviour for the
configured TAP devices after the boot process.
$ diff 3.7.1 3.8.0-rc1+ | grep UP
- br0: flags=4355UP,BROADCAST,PROMISC,MULTICAST mtu 1500
+ br0:
On 11/30/2012 09:28 AM, David Miller wrote:
> From: Jiri Slaby
> Date: Fri, 30 Nov 2012 18:05:40 +0100
>
>> Delivery to the following recipient failed permanently:
>>
>> v...@office.satix.net
>>
>> Technical details of permanent failure:
>> DNS Error: Domain name not found
>>
>> Of course:
On 11/30/2012 09:28 AM, David Miller wrote:
From: Jiri Slaby jsl...@suse.cz
Date: Fri, 30 Nov 2012 18:05:40 +0100
Delivery to the following recipient failed permanently:
v...@office.satix.net
Technical details of permanent failure:
DNS Error: Domain name not found
Of course:
$
On 10/31/2012 10:45 PM, Jason Wang wrote:
> Hello All:
>
> This is an update of multiqueue support in tuntap from V3. Please consider to
> merge.
>
> The main idea for this series is to let tun/tap device to be benefited from
> multiqueue network cards and multi-core host. We used to have a
On 10/31/2012 10:45 PM, Jason Wang wrote:
Hello All:
This is an update of multiqueue support in tuntap from V3. Please consider to
merge.
The main idea for this series is to let tun/tap device to be benefited from
multiqueue network cards and multi-core host. We used to have a single
Hi Paul,
> A couple of proposals have been made recently by people working Linux
> on smaller systems, for improving realtime isolation and memory
> pressure handling:
>
> (1) cpu isolation for hard(er) realtime
> http://lkml.org/lkml/2008/2/21/517
> Max Krasnyanskiy <[EMAIL
Hi Paul,
A couple of proposals have been made recently by people working Linux
on smaller systems, for improving realtime isolation and memory
pressure handling:
(1) cpu isolation for hard(er) realtime
http://lkml.org/lkml/2008/2/21/517
Max Krasnyanskiy [EMAIL PROTECTED]
Hi Thomas,
While reviewing CPU isolation patches Peter pointed out that instead of
changing arch specific irq handling I should be extending genirq code.
Which makes perfect sense. Why didn't I think of that before :)
Basically the idea is that by default isolated CPUs must not get HW
irqs routed
and
therefor seem out of place in the scheduler code.
This patch does not change/affect any existing scheduler functionality.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
arch/x86/Kconfig|1 +
drivers/base/cpu.c
Documented sysfs interface as suggested by Andrew Morton.
Added general documentation that describes how to configure
and use CPU isolation features.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 41 +++
Documentati
Fixed a couple of typos, long lines and referred to the documentation file.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
kernel/Kconfig.cpuisol | 31 +--
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/kernel/Kconfig.cpuisol b/
isolation is disabled.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
kernel/Kconfig.cpuisol |9 +
kernel/workqueue.c | 30 +++---
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/kernel/Kconfig.cpuisol b/kernel/Kconfig.cpuisol
the patch is totally safe but it does not
seem to
cause any instability in real life.
This feature does not add any overhead when disabled. It's marked as
experimental
due to potential issues mentioned above.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
kernel/Kconfig.cpuisol |
Suggested by Andrew Morton:
isolated_cpu_setup() has an on-stack array of NR_CPUS integers. This
will consume 4k of stack on ia64 (at least). We'll just squeak through
for a ittle while, but this needs to be fixed. Just move it into
__initdata.
Signed-off-by: Max Krasnyansky <[EM
on
the isolated CPUs. Users still have the option or routing IRQs
to them by modifying IRQ affinity mask.
I cannot test other archs hence the patch is for x86_64 only.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
arch/x86/kernel/genapic_flat_64.c |4 +++-
1 files changed, 3 inse
on
the isolated CPUs. Users still have the option or routing IRQs
to them by modifying IRQ affinity mask.
I cannot test other archs hence the patch is for x86_64 only.
Signed-off-by: Max Krasnyansky [EMAIL PROTECTED]
---
arch/x86/kernel/genapic_flat_64.c |4 +++-
1 files changed, 3 insertions
Suggested by Andrew Morton:
isolated_cpu_setup() has an on-stack array of NR_CPUS integers. This
will consume 4k of stack on ia64 (at least). We'll just squeak through
for a ittle while, but this needs to be fixed. Just move it into
__initdata.
Signed-off-by: Max Krasnyansky [EMAIL
isolation is disabled.
Signed-off-by: Max Krasnyansky [EMAIL PROTECTED]
---
kernel/Kconfig.cpuisol |9 +
kernel/workqueue.c | 30 +++---
2 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/kernel/Kconfig.cpuisol b/kernel/Kconfig.cpuisol
index
but it does not
seem to
cause any instability in real life.
This feature does not add any overhead when disabled. It's marked as
experimental
due to potential issues mentioned above.
Signed-off-by: Max Krasnyansky [EMAIL PROTECTED]
---
kernel/Kconfig.cpuisol | 15 +++
kernel
Fixed a couple of typos, long lines and referred to the documentation file.
Signed-off-by: Max Krasnyansky [EMAIL PROTECTED]
---
kernel/Kconfig.cpuisol | 31 +--
1 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/kernel/Kconfig.cpuisol b/kernel
Documented sysfs interface as suggested by Andrew Morton.
Added general documentation that describes how to configure
and use CPU isolation features.
Signed-off-by: Max Krasnyansky [EMAIL PROTECTED]
---
Documentation/ABI/testing/sysfs-devices-system-cpu | 41 +++
Documentation/cpu
and
therefor seem out of place in the scheduler code.
This patch does not change/affect any existing scheduler functionality.
Signed-off-by: Max Krasnyansky [EMAIL PROTECTED]
---
arch/x86/Kconfig|1 +
drivers/base/cpu.c | 48 ++
include
Hi Thomas,
While reviewing CPU isolation patches Peter pointed out that instead of
changing arch specific irq handling I should be extending genirq code.
Which makes perfect sense. Why didn't I think of that before :)
Basically the idea is that by default isolated CPUs must not get HW
irqs routed
Ingo Molnar wrote:
> * Max Krasnyansky <[EMAIL PROTECTED]> wrote:
>
>> Ingo said a few different things (a bit too large to quote).
>
> [...]
>> And at the end he said:
>>> Also, i'd not mind some test-coverage in sched.git as well.
>
>> I fa
Nick Piggin wrote:
> On Wednesday 13 February 2008 17:06, Max Krasnyansky wrote:
>> Nick Piggin wrote:
>
>>> But don't let me dissuade you from making these good improvements
>>> to Linux as well :) Just that it isn't really going to be hard-rt
>>> in gen
Nick Piggin wrote:
On Wednesday 13 February 2008 17:06, Max Krasnyansky wrote:
Nick Piggin wrote:
But don't let me dissuade you from making these good improvements
to Linux as well :) Just that it isn't really going to be hard-rt
in general.
Actually that's the cool thing about CPU
Ingo Molnar wrote:
* Max Krasnyansky [EMAIL PROTECTED] wrote:
Ingo said a few different things (a bit too large to quote).
[...]
And at the end he said:
Also, i'd not mind some test-coverage in sched.git as well.
I far as I know do not mind does not mean must go
Nick Piggin wrote:
> On Wednesday 13 February 2008 14:32, Max Krasnyansky wrote:
>> David Miller wrote:
>>> From: Nick Piggin <[EMAIL PROTECTED]>
>>> Date: Tue, 12 Feb 2008 17:41:21 +1100
>>>
>>>> stop machine is used for more than just module
Steven Rostedt wrote:
> On Tue, 12 Feb 2008, Peter Zijlstra wrote:
>>> Rusty - Stop machine.
>>>After doing a bunch of testing last three days I actually downgraded
>>> stop machine
>>>changes from [highly experimental] to simply [experimental]. Pleas see
>>> this thread
>>>for
Peter Zijlstra wrote:
> On Mon, 2008-02-11 at 20:10 -0800, Max Krasnyansky wrote:
>> Andrew, looks like Linus decided not to pull this stuff.
>> Can we please put it into -mm then.
>>
>> My tree is here
>> git://git.kernel.org/pub/scm/linux/kernel/git/m
David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 17:41:21 +1100
>
>> stop machine is used for more than just module loading and unloading.
>> I don't think you can just disable it.
>
> Right, in particular it is used for CPU hotplug.
Ooops. Totally missed
Peter Zijlstra wrote:
On Mon, 2008-02-11 at 20:10 -0800, Max Krasnyansky wrote:
Andrew, looks like Linus decided not to pull this stuff.
Can we please put it into -mm then.
My tree is here
git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git
Please use 'master' branch
David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 17:41:21 +1100
stop machine is used for more than just module loading and unloading.
I don't think you can just disable it.
Right, in particular it is used for CPU hotplug.
Ooops. Totally missed that. And a
Steven Rostedt wrote:
On Tue, 12 Feb 2008, Peter Zijlstra wrote:
Rusty - Stop machine.
After doing a bunch of testing last three days I actually downgraded
stop machine
changes from [highly experimental] to simply [experimental]. Pleas see
this thread
for more info:
Nick Piggin wrote:
On Wednesday 13 February 2008 14:32, Max Krasnyansky wrote:
David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 17:41:21 +1100
stop machine is used for more than just module loading and unloading.
I don't think you can just disable it.
Right
Andrew, looks like Linus decided not to pull this stuff.
Can we please put it into -mm then.
My tree is here
git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git
Please use 'master' branch (or 'for-linus' they are identical).
There are no changes since last time I sent it.
Andrew, looks like Linus decided not to pull this stuff.
Can we please put it into -mm then.
My tree is here
git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git
Please use 'master' branch (or 'for-linus' they are identical).
There are no changes since last time I sent it.
Paul Jackson wrote:
> Max wrote:
>> Linus, please pull CPU isolation extensions from
>
> Did I miss something in this discussion? I thought
> Ingo was quite clear, and Linus pretty clear too,
> that this patch should bake in *-mm or some such
> place for a bit first.
>
Andrew said:
> The
Linus, please pull CPU isolation extensions from
git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git for-linus
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 41 +++
Documentation/cpu-isolation.txt| 113 +
Linus, please pull CPU isolation extensions from
git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git for-linus
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 41 +++
Documentation/cpu-isolation.txt| 113 +
Paul Jackson wrote:
Max wrote:
Linus, please pull CPU isolation extensions from
Did I miss something in this discussion? I thought
Ingo was quite clear, and Linus pretty clear too,
that this patch should bake in *-mm or some such
place for a bit first.
Andrew said:
The feature as a
Hi Rusty,
I was hopping you could answer a couple of questions about module
loading/unloading
and the stop machine.
There was a recent discussion on LKML about CPU isolation patches I'm working
on.
One of the patches makes stop machine ignore the isolated CPUs. People of
course had
questions
Hi Ingo,
Thanks for your reply.
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>> On Wed, 6 Feb 2008, Max Krasnyansky wrote:
>>> Linus, please pull CPU isolation extensions from
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6
Kok, Auke wrote:
> Max Krasnyansky wrote:
>> Kok, Auke wrote:
>>> Max Krasnyansky wrote:
>>>> Kok, Auke wrote:
>>>>> Max Krasnyansky wrote:
>>>>>> So you don't think it's related to the interrupt coalescing by any
>>>&
Kok, Auke wrote:
> Max Krasnyansky wrote:
>> Kok, Auke wrote:
>>> Max Krasnyansky wrote:
>>>> So you don't think it's related to the interrupt coalescing by any chance ?
>>>> I'd suggest to try and disable the coalescing and see if it makes any
>
Paul Jackson wrote:
> Max - Andrew wondered if the rt tree had seen the
> code or commented it on it. What became of that?
I just replied to Andrew. It's not an RT feature per se.
And yes Peter CC'ed RT folks. You probably did not get a chance to read all
replies.
They had some
Andrew Morton wrote:
> On Thu, 7 Feb 2008 01:59:54 -0600 Paul Jackson <[EMAIL PROTECTED]> wrote:
>
>> but hard real time is not my expertise
>
> Speaking of which.. there is the -rt tree. Have those people had a look
> at the feature, perhaps played with the code?
Peter Z. and Steven R. sent
Kok, Auke wrote:
> Max Krasnyansky wrote:
>> So you don't think it's related to the interrupt coalescing by any chance ?
>> I'd suggest to try and disable the coalescing and see if it makes any
>> difference.
>> We've had lots of issues with coalescing misbehavior. No
Paul Jackson wrote:
> Andrew wrote:
>> (and bear in mind that Paul has a track record of being wrong
>> on this :))
>
> heh - I saw that .
>
> Max - Andrew's about right, as usual. You answered my initial
> questions on this patch set adequately, but hard real time is
> not my expertise, so
Hi Linus,
Linus Torvalds wrote:
>
> On Wed, 6 Feb 2008, Max Krasnyansky wrote:
>> Linus, please pull CPU isolation extensions from
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git for-linus
>
> Have these been in -mm and widely discuss
Andrew Morton wrote:
> On Wed, 06 Feb 2008 21:32:55 -0800 Max Krasnyansky <[EMAIL PROTECTED]> wrote:
>
>> Linus, please pull CPU isolation extensions from
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git for-linus
>
> The feature
Pavel Machek wrote:
> Hi!
>
> I have the famous e1000 latency problems:
>
> 64 bytes from 195.113.31.123: icmp_seq=68 ttl=56 time=351.9 ms
> 64 bytes from 195.113.31.123: icmp_seq=69 ttl=56 time=209.2 ms
> 64 bytes from 195.113.31.123: icmp_seq=70 ttl=56 time=1004.1 ms
> 64 bytes from
Andrew Morton wrote:
On Thu, 7 Feb 2008 01:59:54 -0600 Paul Jackson [EMAIL PROTECTED] wrote:
but hard real time is not my expertise
Speaking of which.. there is the -rt tree. Have those people had a look
at the feature, perhaps played with the code?
Peter Z. and Steven R. sent me some
Kok, Auke wrote:
Max Krasnyansky wrote:
Kok, Auke wrote:
Max Krasnyansky wrote:
Kok, Auke wrote:
Max Krasnyansky wrote:
So you don't think it's related to the interrupt coalescing by any
chance ?
I'd suggest to try and disable the coalescing and see if it makes any
difference.
We've
Kok, Auke wrote:
Max Krasnyansky wrote:
Kok, Auke wrote:
Max Krasnyansky wrote:
So you don't think it's related to the interrupt coalescing by any chance ?
I'd suggest to try and disable the coalescing and see if it makes any
difference.
We've had lots of issues with coalescing
Hi Linus,
Linus Torvalds wrote:
On Wed, 6 Feb 2008, Max Krasnyansky wrote:
Linus, please pull CPU isolation extensions from
git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git for-linus
Have these been in -mm and widely discussed etc? I'd like to start more
carefully
Paul Jackson wrote:
Max - Andrew wondered if the rt tree had seen the
code or commented it on it. What became of that?
I just replied to Andrew. It's not an RT feature per se.
And yes Peter CC'ed RT folks. You probably did not get a chance to read all
replies.
They had some
Paul Jackson wrote:
Andrew wrote:
(and bear in mind that Paul has a track record of being wrong
on this :))
heh - I saw that grin.
Max - Andrew's about right, as usual. You answered my initial
questions on this patch set adequately, but hard real time is
not my expertise, so in the
Hi Ingo,
Thanks for your reply.
* Linus Torvalds [EMAIL PROTECTED] wrote:
On Wed, 6 Feb 2008, Max Krasnyansky wrote:
Linus, please pull CPU isolation extensions from
git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git
for-linus
Have these been in -mm and widely discussed
Hi Rusty,
I was hopping you could answer a couple of questions about module
loading/unloading
and the stop machine.
There was a recent discussion on LKML about CPU isolation patches I'm working
on.
One of the patches makes stop machine ignore the isolated CPUs. People of
course had
questions
Linus, please pull CPU isolation extensions from
git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git for-linus
Diffstat:
b/arch/x86/Kconfig |1
b/arch/x86/kernel/genapic_flat_64.c |5 ++-
b/drivers/base/cpu.c| 48
Linus, please pull CPU isolation extensions from
git://git.kernel.org/pub/scm/linux/kernel/git/maxk/cpuisol-2.6.git for-linus
Diffstat:
b/arch/x86/Kconfig |1
b/arch/x86/kernel/genapic_flat_64.c |5 ++-
b/drivers/base/cpu.c| 48
Daniel Walker wrote:
> On Mon, Feb 04, 2008 at 03:35:13PM -0800, Max Krasnyanskiy wrote:
>> This is just an FYI. As part of the "Isolated CPU extensions" thread Daniel
>> suggest for me
>> to check out latest RT kernels. So I did or at least tried to and
>> immediately spotted a couple
>> of
Paul Jackson wrote:
> Max K wrote:
>>> And for another thing, we already declare externs in cpumask.h for
>>> the other, more widely used, cpu_*_map variables cpu_possible_map,
>>> cpu_online_map, and cpu_present_map.
>> Well, to address #2 and #3 isolated map will need to be
Paul Jackson wrote:
Max K wrote:
And for another thing, we already declare externs in cpumask.h for
the other, more widely used, cpu_*_map variables cpu_possible_map,
cpu_online_map, and cpu_present_map.
Well, to address #2 and #3 isolated map will need to be exported as well.
Daniel Walker wrote:
On Mon, Feb 04, 2008 at 03:35:13PM -0800, Max Krasnyanskiy wrote:
This is just an FYI. As part of the Isolated CPU extensions thread Daniel
suggest for me
to check out latest RT kernels. So I did or at least tried to and
immediately spotted a couple
of issues.
The
Hi Daniel,
Sorry for not replying right away.
Daniel Walker wrote:
> On Mon, 2008-01-28 at 16:12 -0800, Max Krasnyanskiy wrote:
>
>> Not accurate enough and way too much overhead for what I need. I know at
>> this point it probably
>> sounds like I'm talking BS :). I wish I've released the
Paul Jackson wrote:
> Max wrote:
>> Paul, I actually mentioned at the beginning of my email that I did read that
>> thread
>> started by Peter. I did learn quite a bit from it :)
>
> Ah - sorry - I missed that part. However, I'm still getting the feeling
> that there were some key points in
Paul Jackson wrote:
Max wrote:
Paul, I actually mentioned at the beginning of my email that I did read that
thread
started by Peter. I did learn quite a bit from it :)
Ah - sorry - I missed that part. However, I'm still getting the feeling
that there were some key points in that thread
Hi Daniel,
Sorry for not replying right away.
Daniel Walker wrote:
On Mon, 2008-01-28 at 16:12 -0800, Max Krasnyanskiy wrote:
Not accurate enough and way too much overhead for what I need. I know at
this point it probably
sounds like I'm talking BS :). I wish I've released the engine and
Paul Jackson wrote:
> Max wrote:
>> Here is the list of things of issues with sched_load_balance flag from CPU
>> isolation
>> perspective:
>
> A separate thread happened to start up on lkml.org, shortly after
> yours, that went into this in considerable detail.
>
> For example, the
Paul Jackson wrote:
Max wrote:
Here is the list of things of issues with sched_load_balance flag from CPU
isolation
perspective:
A separate thread happened to start up on lkml.org, shortly after
yours, that went into this in considerable detail.
For example, the interaction of
Robert Hancock wrote:
> Can you post the full dmesg output? What kind of drive is this?
Sorry for the delay. I'm on vacation and have sporadic email access.
Full dmesg is pretty long. Here SATA related section.
sata_nv :00:07.0: version 3.4
ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
Andrew Morton wrote:
> On Mon, 29 Oct 2007 09:54:27 -0700
> Max Krasnyansky <[EMAIL PROTECTED]> wrote:
>
>> A couple of HP xw9300 machines (dual Opterons) started freezing up.
>> We're running on 2.6.22.1 on them. Freezes a somewhere weird. VGA console is
>>
Andrew Morton wrote:
On Mon, 29 Oct 2007 09:54:27 -0700
Max Krasnyansky [EMAIL PROTECTED] wrote:
A couple of HP xw9300 machines (dual Opterons) started freezing up.
We're running on 2.6.22.1 on them. Freezes a somewhere weird. VGA console is
alive
(I can switch vts, etc) but everything
Robert Hancock wrote:
Can you post the full dmesg output? What kind of drive is this?
Sorry for the delay. I'm on vacation and have sporadic email access.
Full dmesg is pretty long. Here SATA related section.
sata_nv :00:07.0: version 3.4
ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
A couple of HP xw9300 machines (dual Opterons) started freezing up.
We're running on 2.6.22.1 on them. Freezes a somewhere weird. VGA console is
alive
(I can switch vts, etc) but everything else is dead (network, etc).
Unfortunately SYSRQ was not enabled and I could not get backtraces and stuff.
A couple of HP xw9300 machines (dual Opterons) started freezing up.
We're running on 2.6.22.1 on them. Freezes a somewhere weird. VGA console is
alive
(I can switch vts, etc) but everything else is dead (network, etc).
Unfortunately SYSRQ was not enabled and I could not get backtraces and stuff.
Joe Perches wrote:
MAINTAINERS curently has:
TUN/TAP driver
P: Maxim Krasnyansky
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
[EMAIL PROTECTED] doesn't seem to be a valid email address.
Should it be removed or modified?
Sorry for late response. Just noticed this.
Yes it's an
Joe Perches wrote:
MAINTAINERS curently has:
TUN/TAP driver
P: Maxim Krasnyansky
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
[EMAIL PROTECTED] doesn't seem to be a valid email address.
Should it be removed or modified?
Sorry for late response. Just noticed this.
Yes it's an
Jeff Dike wrote:
I recieved from Guido Guenther the patch below to the TUN/TAP driver
which allows group ownerships to be effective.
It seems reasonable to me.
Looks good to me too. We'll add to my tree. In the mean time I don't
mind if one of net drv maintainers pushes it upstream.
Thanx
Jeff Dike wrote:
I recieved from Guido Guenther the patch below to the TUN/TAP driver
which allows group ownerships to be effective.
It seems reasonable to me.
Looks good to me too. We'll add to my tree. In the mean time I don't
mind if one of net drv maintainers pushes it upstream.
Thanx
Christoph Lameter wrote:
> On Tue, 20 Feb 2007, Max Krasnyansky wrote:
>
>> Suppose I need to isolate a CPU. We already support at the scheduler and
>> irq levels (irq affinity). But I want to go a bit further and avoid
>> doing kernel work on isolated cpus as much as
Christoph Lameter wrote:
On Tue, 20 Feb 2007, Max Krasnyansky wrote:
Ok. Sounds like disabling cache_reaper is a better option for now. Like you said
it's unlikely that slabs will grow much if that cpu is not heavily used by the
kernel.
Running for prolonged times without cache_reaper
Christoph Lameter wrote:
On Tue, 20 Feb 2007, Max Krasnyansky wrote:
I guess I kind of hijacked the thread. The second part of my first email was
dropped. Basically I was saying that I'm working on CPU isolation extensions.
Where an isolated CPU is not supposed to do much kernel work. In which
Oleg Nesterov wrote:
On 02/20, Christoph Lameter wrote:
On Tue, 20 Feb 2007, Max Krasnyansky wrote:
Well seems that we have a set of unresolved issues with workqueues and cpu
hotplug.
How about storing 'cpu' explicitly in the work queue instead of relying on the
smp_processor_id
Christoph Lameter wrote:
On Tue, 20 Feb 2007, Max Krasnyansky wrote:
Well seems that we have a set of unresolved issues with workqueues and cpu
hotplug.
How about storing 'cpu' explicitly in the work queue instead of relying on the
smp_processor_id() and friends ? That way
Folks,
Oleg Nesterov wrote:
Even if smp_processor_id() was stable during the execution of cache_reap(),
this work_struct can be moved to another CPU if CPU_DEAD happens. We can't
avoid this, and this is correct.
Uhh This may not be correct in terms of how the slab operates.
But this is
Folks,
Oleg Nesterov wrote:
Even if smp_processor_id() was stable during the execution of cache_reap(),
this work_struct can be moved to another CPU if CPU_DEAD happens. We can't
avoid this, and this is correct.
Uhh This may not be correct in terms of how the slab operates.
But this is
Christoph Lameter wrote:
On Tue, 20 Feb 2007, Max Krasnyansky wrote:
Well seems that we have a set of unresolved issues with workqueues and cpu
hotplug.
How about storing 'cpu' explicitly in the work queue instead of relying on the
smp_processor_id() and friends ? That way
Oleg Nesterov wrote:
On 02/20, Christoph Lameter wrote:
On Tue, 20 Feb 2007, Max Krasnyansky wrote:
Well seems that we have a set of unresolved issues with workqueues and cpu
hotplug.
How about storing 'cpu' explicitly in the work queue instead of relying on the
smp_processor_id
Christoph Lameter wrote:
On Tue, 20 Feb 2007, Max Krasnyansky wrote:
I guess I kind of hijacked the thread. The second part of my first email was
dropped. Basically I was saying that I'm working on CPU isolation extensions.
Where an isolated CPU is not supposed to do much kernel work. In which
Christoph Lameter wrote:
On Tue, 20 Feb 2007, Max Krasnyansky wrote:
Ok. Sounds like disabling cache_reaper is a better option for now. Like you said
it's unlikely that slabs will grow much if that cpu is not heavily used by the
kernel.
Running for prolonged times without cache_reaper
Christoph Lameter wrote:
On Tue, 20 Feb 2007, Max Krasnyansky wrote:
Suppose I need to isolate a CPU. We already support at the scheduler and
irq levels (irq affinity). But I want to go a bit further and avoid
doing kernel work on isolated cpus as much as possible. For example I
would
Using gtod() can amount to a substantial disturbance of the thing to
be measured. Using rdtsc, things seem reliable so far, and we have an
FPGA (accessed through the PCI bus) that has been programmed to give
access to an 8MHz clock and we do some checks against that.
Same here.
Using gtod() can amount to a substantial disturbance of the thing to
be measured. Using rdtsc, things seem reliable so far, and we have an
FPGA (accessed through the PCI bus) that has been programmed to give
access to an 8MHz clock and we do some checks against that.
Same here.
Hi Folks,
I've got ASUS DVD-E616P2 drive and it seems that media detection is broken with
it.
Processes that try to access the drive when cd or dvd is not inserted simply
hang until the machine is rebooted.
So for example if I do 'cat /dev/cdrom'. First few attempts fail with 'No
medium found'
1 - 100 of 101 matches
Mail list logo
