From: Anton Ivanov
For more details see:
http://stackoverflow.com/questions/4624071/pipe-buffer-size-is-4k-or-64k
The observations on that thread have been confirmed by us for UML's
UBD driver. If you load UML with network IO and do disk IO at the same
time the UBD IO helper thread fai
From: Anton Ivanov
Signed-off-by: Anton Ivanov
---
arch/um/os-Linux/main.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/um/os-Linux/main.c b/arch/um/os-Linux/main.c
index 7a86dd5..048166d 100644
--- a/arch/um/os-Linux/main.c
+++ b/arch/um/os-Linux/main.c
@@ -149,6 +149,7 @@ int
From: Anton Ivanov
The reverse case of this race (you must msync before read) is
well known. This is the not so common one.
It can be triggered only on systems which do a lot of task
switching and only at UML startup. If you are starting 200+ UMLs
~ 0.5% will always die without this fix
076 and 741075.
By the way - this means that the request disposal and handling of failed
requests in the UBD driver is wrong somewhere else. No idea where.
A.
On 08/03/14 06:51, anton.iva...@kot-begemot.co.uk wrote:
> From: Anton Ivanov
>
> For more details see:
>
> http://stacko
From: Anton Ivanov
PIPE is the wrong IPC for this type of inter-thread communication.
For more details see:
http://stackoverflow.com/questions/4624071/pipe-buffer-size-is-4k-or-64k
The observations on that thread have been confirmed by us for UML's
UBD driver. If you load UML with netwo
From: Anton Ivanov
UML does not handle sigpipe. As a result when running it under
expect or redirecting the IO from the console to an external program
it will crash if the program stops or exits.
Signed-off-by: Anton Ivanov
---
arch/um/os-Linux/main.c |1 +
1 file changed, 1 insertion
From: Anton Ivanov
The reverse case of this race (you must msync before read) is
well known. This is the not so common one.
It can be triggered only on systems which do a lot of task
switching and only at UML startup. If you are starting 200+ UMLs
~ 0.5% will always die without this fix
-list.
A.
On 08/03/14 23:33, Richard Weinberger wrote:
>
> Am 07.03.2014 19:37, schrieb anton.iva...@kot-begemot.co.uk:
>> From: Anton Ivanov
>>
>> PIPE is the wrong IPC for this type of inter-thread communication.
>>
>> For more details see:
>>
>>
From: Anton Ivanov
Obvious performance optimization - it is not necessary
to read the requests one at a time in the IRQ handler
Signed-off-by: Anton Ivanov
---
arch/um/drivers/ubd_kern.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch
From: Anton Ivanov
The epoll based controller has real (not emulated) edge and
level semantics and the edge/level is handled by epoll. There
is no toggling of the poll set any more, thus it is removed
throughout
Signed-off-by: Anton Ivanov
---
arch/um/drivers/chan_kern.c |2 --
arch
From: Anton Ivanov
This is an alternative to the well known pcap transport.
In the absense of special hardware support pcap is slow,
guaranteed to be slow and with significant penalties on
NUMA/SMP systems due to the timestamping of every packet.
This transport does not incur any of these
From: Anton Ivanov
The use of the seek()/read() and seek()/write() is a terminal
disease on NUMA. Intense use of this on shared files (f.e.
the master for a COW image) can cause anything up to and including
killing CPUs on unhandled NMIs.
This patch deals with this UML major issue (and one of
From: Anton Ivanov
1. Minimum kernel 2.5.99
2. No "walk the list" lookups for received IRQs - immediate identification
of the correct handler to invoke
3. Full set of IRQ semantics - edge, level, read, write
3.1. Write is now a *REAL* write - so if you (ab)use the
write to si
From: Anton Ivanov
This transport allows a UML to connect to another UML local
or remote, the Linux host or any other network device running
the industry standard Ethernet over GRE protocol. The transport
supports all features of RFC 2784.
The transport supports a common set of features with
From: Anton Ivanov
socketpair() is a better IPC choice for lots of small requests
as it allows deeper (and configurable) queues than pipe()
As a result UBD will process nearly all of the requests submitted
to it instead of bouncing a significant percentage under load
Signed-off-by: Anton
From: Anton Ivanov
Support for multi-packet vector IO - multiple packets
read in one syscall and written in one syscall. Should work with
legacy UML, thorough tested only for the epoll based IRQ controller
Minimal host kernel version for RX - 2.6.32
Minimal host kernel version for TX - 3.0
From: Anton Ivanov
This patch adds an extra timer source which has correct timing
and uses an up-to-date OS API and.
Results - correct kernel behaviour on timer related tasks.
1. Improvement in network performance (TCP state machines
are now fed correct time).
2. Correct QoS and
From: Anton Ivanov
This transport allows a UML to connect to another UML local
or remote, the Linux host or any other network device running
the industry standard Ethernet over L2TPv3 protocol as per
RFC 3931 (and successors).
The transport supports a common set of features with the kernel
From: Anton Ivanov
Support for multi-packet vector IO - multiple packets
read in one syscall and written in one syscall. Should work with
legacy UML, thorough tested only for the epoll based IRQ controller
Minimal host kernel version for RX - 2.6.32
Minimal host kernel
From: Anton Ivanov
This patch adds an extra timer source which has correct timing
and uses an up-to-date OS API and.
Results - correct kernel behaviour on timer related tasks.
1. Improvement in network performance (TCP state machines
are now fed correct time).
2. Correct QoS and
Patch dependencies:
[PATCH v3 01/10] Epoll based interrupt controller
Full redesign of the existing UML poll based controller. The old
poll controller incurs huge penalties for IRQ sharing and many devices
setup due to the device list being walked twice.
Additionally, the current controller has
From: Anton Ivanov
This is an alternative to the well known pcap transport.
In the absense of special hardware support pcap is slow,
guaranteed to be slow and with significant penalties on
NUMA/SMP systems due to the timestamping of every packet.
This transport does not incur any of these
From: Anton Ivanov
The epoll based controller has real (not emulated) edge and
level semantics and the edge/level is handled by epoll. There
is no toggling of the poll set any more, thus it is removed
throughout
Signed-off-by: Anton Ivanov
---
arch/um/drivers/chan_kern.c |2 --
arch
From: Anton Ivanov
Obvious performance optimization - it is not necessary
to read the requests one at a time in the IRQ handler
Signed-off-by: Anton Ivanov
---
arch/um/drivers/ubd_kern.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch
From: Anton Ivanov
The use of the seek()/read() and seek()/write() is a terminal
disease on NUMA. Intense use of this on shared files (f.e.
the master for a COW image) can cause anything up to and including
killing CPUs on unhandled NMIs.
This patch deals with this UML major issue (and one of
From: Anton Ivanov
This transport allows a UML to connect to another UML local
or remote, the Linux host or any other network device running
the industry standard Ethernet over GRE protocol. The transport
supports all features of RFC 2784.
The transport supports a common set of features with
From: Anton Ivanov
This transport allows a UML to connect to another UML local
or remote, the Linux host or any other network device running
the industry standard Ethernet over L2TPv3 protocol as per
RFC 3931 (and successors).
The transport supports a common set of features with the kernel
From: Anton Ivanov
1. Minimum kernel 2.5.99
2. No "walk the list" lookups for received IRQs - immediate identification
of the correct handler to invoke
3. Full set of IRQ semantics - edge, level, read, write
3.1. Write is now a *REAL* write - so if you (ab)use the
write to si
From: Anton Ivanov
socketpair() is a better IPC choice for lots of small requests
as it allows deeper (and configurable) queues than pipe()
As a result UBD will process nearly all of the requests submitted
to it instead of bouncing a significant percentage under load
Signed-off-by: Anton
From: Anton Ivanov
Support for multi-packet vector IO - multiple packets
read in one syscall and (optionally) written in one syscall.
Support for (optional) queueing on EAGAIN/ENOBUFS - applies
only to socket transports. Sorry TAP, -EYOULOSE - it will remain
slower than any
From: Anton Ivanov
This patch adds an extra timer source which has correct timing
and uses an up-to-date OS API and.
Results - correct kernel behaviour on timer related tasks.
1. Improvement in network performance (TCP state machines
are now fed correct time).
2. Correct QoS and
Hi list,
Some benchmarks (current version, I believe this can do more once it
gains full epoll write support).
4 UMLs running in parallel, each pinned to a core, new raw driver - vlan
per UML, 10G NIC on 4 core 3.5GHz A8 connected back to back to an 8 core
machine running iperf server.
Server
This is an update of the performance improvement patchset, it
addresses a number of issues resulting from porting what was
originally written for 3.3.8 to the current linux kernel.
Changes (where applicable) are annotated in actual patchsets.
A.
From: Anton Ivanov
Obvious performance optimization - it is not necessary
to read the requests one at a time in the IRQ handler
Signed-off-by: Anton Ivanov
---
arch/um/drivers/ubd_kern.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/arch
From: Anton Ivanov
This is an alternative to the well known pcap transport.
In the absense of special hardware support pcap is slow,
guaranteed to be slow and with significant penalties on
NUMA/SMP systems due to the timestamping of every packet.
This transport does not incur any of these
From: Anton Ivanov
socketpair() is a better IPC choice for lots of small requests
as it allows deeper (and configurable) queues than pipe()
As a result UBD will process nearly all of the requests submitted
to it instead of bouncing a significant percentage under load
Signed-off-by: Anton
From: Anton Ivanov
The use of the seek()/read() and seek()/write() is a terminal
disease on NUMA. Intense use of this on shared files (f.e.
the master for a COW image) can cause anything up to and including
killing CPUs on unhandled NMIs.
This patch deals with this UML major issue (and one of
From: Anton Ivanov
The epoll based controller has real (not emulated) edge and
level semantics and the edge/level is handled by epoll. There
is no toggling of the poll set any more, thus it is removed
throughout
Signed-off-by: Anton Ivanov
---
arch/um/drivers/chan_kern.c |2 --
arch
From: Anton Ivanov
Support for multi-packet vector IO - multiple packets
read in one syscall and (optionally) written in one syscall.
Support for (optional) queueing on EAGAIN/ENOBUFS - applies
only to socket transports. Sorry TAP, -EYOULOSE - it will remain
slower than any
From: Anton Ivanov
1. Minimum kernel 2.5.44
2. No "walk the list" lookups for received IRQs - immediate identification
of the correct handler to invoke
3. Full set of IRQ semantics - edge, level, read, write
3.1. Write is now a *REAL* write - so if you (ab)use the
write to si
From: Anton Ivanov
This transport allows a UML to connect to another UML local
or remote, the Linux host or any other network device running
the industry standard Ethernet over GRE protocol. The transport
supports all features of RFC 2784.
The transport supports a common set of features with
From: Anton Ivanov
This patch adds an extra timer source which has correct timing
and uses an up-to-date OS API and.
Results - correct kernel behaviour on timer related tasks.
1. Improvement in network performance (TCP state machines
are now fed correct time).
2. Correct QoS and
From: Anton Ivanov
If the ubd is asynchronous the amount of time uml will spend
fsync-ing on FLUSH is unpredictable. There are bits in the upper fs
layers that really dislike this. Replacing fsync() with an
async flush request via sync_file_range mitigates this (somewhat),
improves performance
-0002Zt-Ty; Mon, 22 Sep 2014 17:53:28 +0100
From: anton.iva...@kot-begemot.co.uk
To: user-mode-linux-devel@lists.sourceforge.net
Cc: Anton Ivanov
Subject: [PATCH v4 04/11] L2TPv3 Transport Driver for UML
Date: Mon, 22 Sep 2014 17:53:17 +0100
Message-Id: <1411404804-871910-5-git-send-email-anton.
On 23/09/14 15:58, Rob Landley wrote:
> On 09/22/14 13:39, Anton Ivanov wrote:
>> Hi RIchard, hi list,
>>
>> There is some problem with the list on sourceforge. It has bounced one
>> of the patches - no 4.
>>
>> I can resend this for book-keeping purposes.
&g
I finally nailed the last stability issue related to the patchset this
morning. It is an extremely old issue and I tried to locate the root
cause for it with Richard off-list 2 years ago. Unfortunately it was
without success at that time.
This issue is inherent in "stock" UML, but very difficul
From: Anton Ivanov
This is a fix for a very old UML bug which can be triggered with stock
UML. It takes a lot of effort to trigger it there because the
lseek()/read() | write() mechanics of the UBD driver implicitly sync the
memory all the time by hitting the appropriate barrier
From: Anton Ivanov
Occasionally, under very heavy load inside UML, on host
or both one of the processes in UML will remain in D state
or will fail to reap a child which will sit in Z state.
This is very difficult to reproduce with stock UML because
the lseek()/read()|write()|fsync() in the ubd
On 26/09/14 12:56, Richard Weinberger wrote:
> Am 26.09.2014 13:49, schrieb anton.iva...@kot-begemot.co.uk:
>> From: Anton Ivanov
>>
>> This is a fix for a very old UML bug which can be triggered with stock
>> UML. It takes a lot of effort to trigger it there b
How does the stall manifest itself?
Do you have the journal thread (and sometimes a couple of other threads)
sitting in D state?
A.
On 13/10/14 22:48, Thomas Meyer wrote:
> #0 balance_dirty_pages_ratelimited (mapping=0x792cc618) at
> mm/page-writeback.c:1587
> #1 0x600ba54f in do_wp_p
On 14/10/14 06:38, Anton Ivanov wrote:
> How does the stall manifest itself?
>
> Do you have the journal thread (and sometimes a couple of other threads)
> sitting in D state?
Sorry, should not be asking questions at 6 am before the 3rd double
espresso.
I think it is the same bug
100 schrieb Anton Ivanov:
>> On 14/10/14 06:38, Anton Ivanov wrote:
>>> How does the stall manifest itself?
>>>
>>> Do you have the journal thread (and sometimes a couple of other threads)
>>> sitting in D state?
>> Sorry, should not be asking questions
On 19/10/14 15:59, Thomas Meyer wrote:
> Am Dienstag, den 14.10.2014, 08:31 +0100 schrieb Anton Ivanov:
>> I see a very similar stall on writeout to ubd with my patches (easy) and
>> without (difficult - takes running an IO soak for a few days).
>>
>> It stalls (usuall
35 +0200 schrieb Thomas Meyer:
>> Am Sonntag, den 19.10.2014, 17:02 +0100 schrieb Anton Ivanov:
>>> On 19/10/14 15:59, Thomas Meyer wrote:
>>>> Am Dienstag, den 14.10.2014, 08:31 +0100 schrieb Anton Ivanov:
>>>>> I see a very similar stall on writeout to ubd w
On 23/10/14 09:36, Richard Weinberger wrote:
> Anton,
>
> Am 23.10.2014 um 09:34 schrieb Anton Ivanov:
>> Hi Richard,
>>
>> I have had a question in my mind on this for quite a while around this bug
>> (and a quite a few others).
> Fell free to ask, I'll
I have seen this a couple of times as well.
I am a bit snowed under at the moment, when I have some spare time I
will try to dig through my trees to see exactly what did I come up with
as a root cause.
A.
On 19/11/14 17:06, Toralf Förster wrote:
> /me wonders, why the same call few seconds later
On 26/04/15 22:00, Richard Weinberger wrote:
>
>>> Can you give the attached patch a try?
>>> Let's see if it proves my theory.
>>> Looks like UML's clocksource needs fixing.
>> Hi Richard,
>>
>> I did run this for an hour and did 4 suspend/resume cycles and it seems
>> not to hang any more!
> Yay!
On 27/04/15 08:23, Richard Weinberger wrote:
> On Mon, Apr 27, 2015 at 7:47 AM, Anton Ivanov
> wrote:
>> On 26/04/15 22:00, Richard Weinberger wrote:
>>>>> Can you give the attached patch a try?
>>>>> Let's see if it proves my theory.
>>&
On 02/05/15 10:48, Thomas Meyer wrote:
> Hi,
>
> I did port Anton's v4 patch to v4.1-rc1-56-g3d99e3f and run it the last
> two days.
>
> Original v4 from Anton can be found here:
> https://sourceforge.net/p/user-mode-linux/mailman/message/32856805/
>
> Issues addressed in v5 version:
> - Ported
, 12:08 +0100 schrieb Anton Ivanov:
>> On 02/05/15 10:48, Thomas Meyer wrote:
>>> Hi,
>>>
>>> I did port Anton's v4 patch to v4.1-rc1-56-g3d99e3f and run it the last
>>> two days.
>>>
>>> Original v4 from Anton can be foun
that cannot be helped at this stage.
A.
On 03/05/15 16:46, Thomas Meyer wrote:
> Am Samstag, den 02.05.2015, 12:08 +0100 schrieb Anton Ivanov:
>> On 02/05/15 10:48, Thomas Meyer wrote:
>>> Hi,
>>>
>>> I did port Anton's v4 patch to v4.1-rc1-56-
On 05/05/15 08:00, Thomas Meyer wrote:
>
>> Am 04.05.2015 um 18:22 schrieb Anton Ivanov :
>>
>> Hi Thomas,
> Hi Anton,
>
>> I read it and like it except idle sleep. See my comments inline. I
>> killed that nanosleep quite on purpose :)
> Okay. I think
On 10/05/15 13:35, Richard Weinberger wrote:
> On Sun, May 10, 2015 at 1:14 AM, Thomas Meyer wrote:
>> Hi,
>>
>> Changes:
>> - also create posix timer in stub_clone_handler()
>> - incorporated antons remarks
> Hm, this patch does a *lot* more than the changelog says.
Richard, I think this is what
On 10/05/15 15:34, Thomas Meyer wrote:
>> Am 10.05.2015 um 14:35 schrieb Richard Weinberger
>> :
>>
>>> On Sun, May 10, 2015 at 1:14 AM, Thomas Meyer wrote:
>>> Hi,
>>>
>>> Changes:
>>> - also create posix timer in stub_clone_handler()
>>> - incorporated antons remarks
>> Hm, this patch does a *l
Hurray, Houston we have ignition.
We now have working userspace timers.
It is still schizophrenic - userspace is HZ, kernel is NOHZ because the
userpace has to keep checking "did the kernel timer fire yet" at a HZ
interval. However, even that is a major progress compared to having
userspace timer
positive side - the behavior we are getting now is better, so we
just need to figure out the root cause for the hang(s) and stabilize it.
A.
On 11/05/15 13:52, Anton Ivanov wrote:
> Hurray, Houston we have ignition.
>
> We now have working userspace timers.
>
> It is still schizophrenic
e clearly
the "logical" replacement where the timer fires exactly when it is
expected to fire does not quite work. So what is the idea here?
A.
On 11/05/15 16:05, Anton Ivanov wrote:
> Hi Thomas, hi Richard,
>
> It is now possible to reproducibly hang it. I have not been able to
>
On 11/05/15 18:00, Thomas Meyer wrote:
> Hi,
>
> maybe there is a bug in how the timers are created for all user space
> processes.
> In the latest patch I use os__timer_remain for the initial interval.
> The idea was to launch all timers at the same time. But I now think this can
> never work us
On 11/05/15 18:20, Anton Ivanov wrote:
> On 11/05/15 18:00, Thomas Meyer wrote:
>> Hi,
>>
>> maybe there is a bug in how the timers are created for all user space
>> processes.
>> In the latest patch I use os__timer_remain for the initial interval.
>> The id
On 11/05/15 18:41, Thomas Meyer wrote:
> Am 11.05.2015 7:31 nachm. schrieb Anton Ivanov
> :
>> On 11/05/15 18:20, Anton Ivanov wrote:
>>> On 11/05/15 18:00, Thomas Meyer wrote:
>>>> Hi,
>>>>
>>>> maybe there is a bug in how the timers ar
Same story.
Overall works quite well, the moment I give it the "dselect upgrade
test" the userspace hangs.
Kernel continues to work - forwarding, icmp, uml_mconsole are fine.
A.
On 17/05/15 10:25, Thomas Meyer wrote:
> Switch the UML clocksource from interval timers to posix interval timers
>
On 19/05/15 17:39, Richard Weinberger wrote:
> On Tue, May 19, 2015 at 6:19 PM, Anton Ivanov
> wrote:
>> Same story.
>>
>> Overall works quite well, the moment I give it the "dselect upgrade
>> test" the userspace hangs.
>>
>> Kernel continu
On 31/05/15 20:00, Thomas Meyer wrote:
> Am Sonntag, den 31.05.2015, 13:15 +0200 schrieb Richard Weinberger:
>> Am 20.05.2015 um 07:26 schrieb Thomas Meyer:
>>> Am 20.05.2015 12:12 vorm. schrieb Richard Weinberger <
>>> richard.weinber...@gmail.com>:
On Sun, May 17, 2015 at 11:25 AM, Thomas Me
I will give it a spin before the end of the weekend and run the full
test suite on it.
A.
[snip]
>> Cascading the kernel timer looks like the correct solution.
> Hi,
>
> below patch get's rid of all userspace timers.
> When a kernel timer interrupt is received the userspace process of the
> cor
On 15/08/15 09:15, Richard Weinberger wrote:
> Am 09.08.2015 um 19:53 schrieb Thomas Meyer:
>> Switch the UML clocksource from interval timers to posix interval timers and
>> move to a monotonic timer.
>>
>> This fixes suspend&resume related timer issues and improves network
>> performance
>> as T
If Thomas is busy I can pick it up ~ middle of next week and finish it.
A.
On 18/08/15 10:34, Richard Weinberger wrote:
> On Sat, Aug 15, 2015 at 6:27 PM, Anton Ivanov
> wrote:
>> On 15/08/15 09:15, Richard Weinberger wrote:
>>> Am 09.08.2015 um 19:53 schrieb Thomas Meyer
Thomas, I need to know if you have the time-slices for this or I should
take over and finish it.
In addition to what Richard said I have the epoll based IRQ controller
and high-performance network pipeline which depend on it in the queue.
Brgds,
A.
On 13/10/15 22:45, Richard Weinberger wrote:
up-to-date one, please post it even if it does not patch
cleanly and needs work. I will work on it.
A.
>
> Anton: it would be great if you could finish this patch! Much appreciated!
>
> With kind regards
> Thomas
>
> Am 14.10.2015 8:12 vorm. schrieb Anton Ivanov
> :
>
:
> Am 14.10.2015 11:23 vorm. schrieb Anton Ivanov
> :
>> On 14/10/15 09:25, Thomas Meyer wrote:
>>> Hello everyone,
>>>
>>> I would like to finish this patch, but I'm currently very busy. Sorry!
>> No worries :) I am barely keeping my head above wate
ned-off-by: Anton Ivanov
Signed-off-by: Thomas Meyer
---
arch/um/Makefile| 2 +-
arch/um/include/shared/os.h | 15 +-
arch/um/include/shared/skas/stub-data.h | 5 +-
arch/um/include/shared/timer-internal.h | 13 ++
arch/um/kernel/process.c
ages).
I should be able to get these out of the door early on this week.
A.
P.S. If there is anything to fix on the timer one, please shout.
A.
On 21/10/15 09:42, Anton Ivanov wrote:
> Background: UML is using an obsolete itimer call for
> all timers and "polls" for kernel sp
g a week or so. IMHO 25%
is worth it :)
A.
On 26/10/15 10:12, Richard Weinberger wrote:
> Hi!
>
> Am 25.10.2015 um 19:46 schrieb Anton Ivanov:
>> Hi List, hi Richard,
>>
>> I am going to sort out the UBD patchset next as that has no dependencies on
>> timer and
Richard, can you send me your config.
I have had it running for a couple of days before submission both under
load and idle it was doing OK.
A
On 31/10/15 15:44, Thomas Meyer wrote:
> Am Samstag, den 31.10.2015, 16:30 +0100 schrieb Richard Weinberger:
>> Am 31.10.2015 um 16:24 schrieb Thomas Me
On 31/10/15 19:08, Richard Weinberger wrote:
> Am 31.10.2015 um 17:22 schrieb Anton Ivanov:
>> Richard, can you send me your config.
> Sure. It is basically a defconfig.
I am dragging an old config from some work I did a while back. I will
scrap it and do a defconfig build one I get
I was testing under similar conditions (CPU pinning using taskset -c 0
on a multicore).
I have removed it and run some retests - I cannot reproduce the hang at
this point with my config
I am going to run a defconfig and compare the results to see if this
will give me any insights on the root c
On 02/11/15 08:37, Richard Weinberger wrote:
> Hi!
>
> Am 02.11.2015 um 09:14 schrieb Anton Ivanov:
>> I was testing under similar conditions (CPU pinning using taskset -c 0 on a
>> multicore).
>>
>> I have removed it and run some retests - I cannot reproduce t
On 02/11/15 08:52, Richard Weinberger wrote:
> Am 02.11.2015 um 09:41 schrieb Anton Ivanov:
>> On 02/11/15 08:37, Richard Weinberger wrote:
>>> Hi!
>>>
>>> Am 02.11.2015 um 09:14 schrieb Anton Ivanov:
>>>> I was testing under similar conditions (CPU
[snip]
>>> I'm pretty sure that you don't see the issue as your Jessy userspace uses
>>> nanosleep periodically.
>> There are quite a few things running so this may indeed be the case.
>>
>> What do you use for userspace (so I can try to reproduce this and debug it)?
> Debian Squeeze amd64 with a
On 02/11/15 10:01, Richard Weinberger wrote:
> Am 02.11.2015 um 10:53 schrieb Anton Ivanov:
>> [snip]
>>
>>>>> I'm pretty sure that you don't see the issue as your Jessy userspace uses
>>>>> nanosleep periodically.
>>>>
On 02/11/15 10:59, Anton Ivanov wrote:
> On 02/11/15 10:01, Richard Weinberger wrote:
>> Am 02.11.2015 um 10:53 schrieb Anton Ivanov:
>>> [snip]
>>>
>>>>>> I'm pretty sure that you don't see the issue as your Jessy
>>>>>>
On 02/11/15 10:01, Richard Weinberger wrote:
> Am 02.11.2015 um 10:53 schrieb Anton Ivanov:
>> [snip]
>>
>>>>> I'm pretty sure that you don't see the issue as your Jessy userspace uses
>>>>> nanosleep periodically.
>>>>
ned-off-by: Thomas Meyer
Signed-off-by: Anton Ivanov
---
arch/um/Makefile| 2 +-
arch/um/include/shared/os.h | 18 ++-
arch/um/include/shared/skas/stub-data.h | 7 +-
arch/um/include/shared/timer-internal.h | 13 ++
arch/um/kernel/process.c
On 02/11/15 15:25, Richard Weinberger wrote:
> Am 02.11.2015 um 15:30 schrieb Anton Ivanov:
>> On 02/11/15 10:01, Richard Weinberger wrote:
>>> Am 02.11.2015 um 10:53 schrieb Anton Ivanov:
>>>> [snip]
>>>>
>>>>>>> I'm pretty sur
On 02/11/15 21:50, Richard Weinberger wrote:
> Am 02.11.2015 um 17:16 schrieb Anton Ivanov:
>> -void idle_sleep(unsigned long long nsecs)
>> +/**
>> + * os_idle_sleep() - sleep for a given time of nsecs
>> + * @nsecs: nanoseconds to sleep
>> + */
>> +void
On 02/11/15 22:13, Anton Ivanov wrote:
> On 02/11/15 21:50, Richard Weinberger wrote:
>> Am 02.11.2015 um 17:16 schrieb Anton Ivanov:
>>> -void idle_sleep(unsigned long long nsecs)
>>> +/**
>>> + * os_idle_sleep() - sleep for a given time of nsecs
Cool,
Is there a tree I can pull so I can have the next one (the epoll based
IRQ controller) incremental?
A.
On 06/11/15 21:56, Richard Weinberger wrote:
> Am 02.11.2015 um 17:16 schrieb Anton Ivanov:
>> Background: UML is using an obsolete itimer call for
>> all timers and &qu
Modifying RLIMIT requires including sys/time.h and sys/resource.h
Signed-off-by: Anton Ivanov
---
arch/um/os-Linux/start_up.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/um/os-Linux/start_up.c b/arch/um/os-Linux/start_up.c
index 425162e..c1811df 100644
--- a/arch/um/os-Linux
This decreases the number of syscalls per read/write by half.
Signed-off-by: Anton Ivanov
---
arch/um/drivers/ubd_kern.c | 27 +--
arch/um/include/shared/os.h | 2 ++
arch/um/os-Linux/file.c | 19 +++
3 files changed, 26 insertions(+), 22 deletions
Hi Richard,
This is vs your tree, 4.x master branch in linus repo actually has
sys/resource.h
Pls ignore the patch.
A.
On 08/11/15 14:58, Anton Ivanov wrote:
> Modifying RLIMIT requires including sys/time.h and sys/resource.h
>
> Signed-off-by: Anton Ivanov
> ---
> a
I am going to send in a couple of more which bulk-up the transactions
(this forms most of the improvement) later this week.
This one is obvious - qemu has been using it for ages.
A.
On 08/11/15 15:20, Anton Ivanov wrote:
> This decreases the number of syscalls per read/write by h
1 - 100 of 233 matches
Mail list logo
