I do not think that this is possible without an additional device in the
UML itself.
In fact, if you want two processes in two different UML instances to
communicate in-between themselves you should aim at a UML device. The
kernel device is probably suprlus to requirements as the two UML
ins
uding some of mine).
The joys of having a broken list :(
Whoever posted it, if you are reading it, please re-post again so we can
have a look.
In the meantime we are as you said - x86 only.
A.
On 04/24/18 09:32, Richard Weinberger wrote:
On Fri, Apr 20, 2018 at 6:06 PM, Anton Ivanov
wrote:
On 04/20/18 15:38, Eric W. Biederman wrote:
Today user mode linux only works on x86 and x86_64 and this allows
simplifications of relay_signal.
I believe someone recently fixed the ARM port. I have not had the time
to try the fixes though.
I have added the new list we are migrating to the c
Yes,
Next version though, I have some tweaks enqueued for the socket initialization.
We can combine them with these.
On 29 March 2018 20:51:55 BST, SF Markus Elfring
wrote:
>> Date: Sun, 11 Mar 2018 16:06:16 +0100
>>
>> Some update suggestions were taken into account
>> from static source co
On 03/13/18 13:59, Richard Weinberger wrote:
Am Dienstag, 13. März 2018, 14:24:23 CET schrieb Geert Uytterhoeven:
Hi Richard,
On Mon, Mar 12, 2018 at 4:21 PM, Richard Weinberger wrote:
Am Montag, 12. März 2018, 16:10:45 CET schrieb Brandeburg, Jesse:
Is the list working for everyone?
I go
On 03/12/18 15:10, Brandeburg, Jesse wrote:
Is the list working for everyone?
I got this mail... BTW Sourceforge had a major datacenter issue over the last
few weeks, not sure if that broke something along the way.
Thanks,
I will try to pin it down. A couple of mails where I had the list
HI all,
Is the list working for everyone?
I did not get the last two messages I sent to the list. Nothing in the
logs on my side either - they were accepted by sourceforge, but no
attempts to send them back.
A
--
C
Thanks, looks correct, +1
Richard, can you add it to the next pull.
Thanks in advance,
A.
On 27/01/18 10:55, Christophe JAILLET wrote:
> If 'find_device()' finds something, we set '*error_out' and we should
> return an error. However, 'err' is known to be 0 at this point.
>
> Explicitly retur
Thanks, looks correct, +1
Richard, can you add it to the next pull.
Thanks in advance,
A.
On 27/01/18 10:53, Christophe JAILLET wrote:
> Checking the result of the previous 'kstrdup()' call is expected here, so
> we should test 'params' and not 'str' (which is known to be non-NULL at
> this poi
I think we have a similar patch pending.
Thanks for noticing. I will review and double check vs queued up patches.
A.
On 5 January 2018 07:22:52 GMT+00:00, Wei Yongjun
wrote:
>Add the missing unlock before return from function vector_net_open()
>in the error handling case.
>
>Fixes: ad1f62ab
Both are correct - omissions on my side
Please apply.
A.
On 12/11/17 09:33, Richard Weinberger wrote:
Anton,
Am Samstag, 9. Dezember 2017, 18:09:17 CET schrieb Anton Ivanov:
Thanks,
I guess I missed that one.
A.
On 09/12/17 11:49, Dan Carpenter wrote:
We need to unlock and restore IRQs
On 26/11/17 13:56, Richard Weinberger wrote:
> Anton,
>
> please don't crop the CC list.
Apologies, I wanted to keep the discussion UML side until we have come
up with something.
Will not do it again.
>
> Am Sonntag, 26. November 2017, 14:41:12 CET schrieb Anton Ivanov:
I need to do some reading on this.
First of all - a stupid question: mq's primary advantage is in
multi-core systems as it improves io and core utilization. We are still
single-core in UML and AFAIK this is likely to stay that way, right?
On 26/11/17 13:10, Richard Weinberger wrote:
> This is the
Errata vs todays Linux next and once again, apologies - I checked
out the yesterday's one by mistake.
A.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.li
From: Anton Ivanov
Add missing EXPORT for free_irq_by_fd()
Signed-off-by: Anton Ivanov
---
arch/um/kernel/irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/um/kernel/irq.c b/arch/um/kernel/irq.c
index 980148d56537..6b7f3827d6e4 100644
--- a/arch/um/kernel/irq.c
+++ b/arch/um
Apologies,
Broken stupidometer - i checked out next-20171121 instead of next-20171122
fixing it, errata patch will follow shortly.
A.
On 11/22/17 13:22, Richard Weinberger wrote:
Am Mittwoch, 22. November 2017, 14:09:11 CET schrieb anton.ivanov@kot-
begemot.co.uk:
Resending patchset v11 ve
From: Anton Ivanov
1. Removes the need to walk the IRQ/Device list to determine
who triggered the IRQ.
2. Improves scalability (up to several times performance
improvement for cases with 10s of devices).
3. Improves UML baseline IO performance for one disk + one NIC
use case by up to 10%.
4
Resending patchset v11 versus Linux Next 20171121
Best Regards,
A.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_
Acknowledge, will do it this afternoon.
A.
On 22 November 2017 11:59:35 GMT+00:00, Richard Weinberger
wrote:
>Am Mittwoch, 22. November 2017, 12:57:21 CET schrieb anton.ivanov@kot-
>begemot.co.uk:
>> This revision adds EXPORT for deactivate_irq_by_fd as needed
>> by the random driver with some
From: Anton Ivanov
1. Removes the need to walk the IRQ/Device list to determine
who triggered the IRQ.
2. Improves scalability (up to several times performance
improvement for cases with 10s of devices).
3. Improves UML baseline IO performance for one disk + one NIC
use case by up to 10%.
4
This revision adds EXPORT for deactivate_irq_by_fd as needed
by the random driver with some kernel configs
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.l
irq.c needs an EXPORT_SYMBOL(free_irq_by_fd);
Amended patch coming up shortly.
A.
On 11/22/17 09:33, kbuild test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git
for-linus-4.15-rc1
head: ad1f62ab2bd43b962127af760d59a25ae1c93681
commit: d4560bdc6d38f5c3bf5889f
weird
free_irq_by_fd is defined by irq_user which is included by os.h and that
is included by random.c
I do not quite see how it could end up undefined.
A.
On 11/22/17 09:33, kbuild test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git
for-linus-4.15-rc1
hea
From: Anton Ivanov
1. Removes the need to walk the IRQ/Device list to determine
who triggered the IRQ.
2. Improves scalability (up to several times performance
improvement for cases with 10s of devices).
3. Improves UML baseline IO performance for one disk + one NIC
use case by up to 10%.
4
Follows a version of the patch after a style cleanup. Functionality
features and code have no material changes compared to previous version.
A.
--
Check out the vibrant tech community on one of the world's most
engaging
This is (hopefully) the final version of the epoll + vector IO
patch. It incorporates the TSO fixes for raw and minor errata
for POLL_CONTROLLER.
A.
--
Check out the vibrant tech community on one of the world's most
enga
From: Anton Ivanov
1. Removes the need to walk the IRQ/Device list to determine
who triggered the IRQ.
2. Improves scalability (up to several times performance
improvement for cases with 10s of devices).
3. Improves UML baseline IO performance for one disk + one NIC
use case by up to 10%.
4
On 14/10/17 09:05, Richard Weinberger wrote:
> Am Samstag, 14. Oktober 2017, 00:00:25 CEST schrieb Thomas Meyer:
>> UMLs current_thread_info() unconditionally assumes that the top of the stack
>> contains the thread_info structure.
>> Prevent kcov from using invalid curent_thread_info() data by dis
/12/17 16:44, Anton Ivanov wrote:
Found it.
Two bugs canceling each other.
The bind sequence in: psock_txring_vnet.c is wrong.
It does the following addr.sll_protocol = htons(ETH_P_IP);
before calling bind.
If you set addr.sll_protocol to ETH_P_ALL where it should have been in
the first place
nothing that can be done to the vector
io drivers - the code is correct, it is the host kernel side which is
broken :(
A.
Forwarded Message
Subject:Re: BUG:af_packet fails to TX TSO frames
Date: Wed, 11 Oct 2017 20:39:57 +0100
From: Anton Ivanov
To: Willem de
This is hopefully the final parking position. It has been cleaned up,
updated to fit the current netdev warning/info message conventions
and no longer hangs if the underlying network hard xmit misbehaves.
The issue with raw sockets is a definitive BUG - I have gone through
it with a comb several t
From: Anton Ivanov
1. Removes the need to walk the IRQ/Device list to determine
who triggered the IRQ.
2. Improves scalability (up to several times performance
improvement for cases with 10s of devices).
3. Improves UML baseline IO performance for one disk + one NIC
use case by up to 10%.
4
This is a resubmit of the patch from earlier today. I had
forgotten to include all files - apologies.
A.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.l
From: Anton Ivanov
1. Removes the need to walk the IRQ/Device list to determine
who triggered the IRQ.
2. Improves scalability (up to several times performance
improvement for cases with 10s of devices).
3. Improves UML baseline IO performance for one disk + one NIC
use case by up to 10%.
4
From: Anton Ivanov
1. Provides infrastructure for vector IO using recvmmsg/sendmmsg.
1.1. Multi-message read.
1.2. Multi-message write.
1.3. Optimized queue support for multi-packet enqueue/dequeue.
1.4. BQL/DQL support.
2. Implements transports for several transports as well support
for direct
From: Anton Ivanov
1. TSO/GSO support where applicable or available
RX - raw and tapraw
TX - tap only (raw appears to be hitting a bug in the
af_packet family in the kernel resulting in it being
stuck in a -ENOBUFS loop.
This results in TX/RX TCP performance ~ 2-3 times higher
than qemu on same
Sorry all,
I fat fingered this one, will resubmit once I get back home and redo it
(I am traveling all day).
A.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! ht
From: Anton Ivanov
1. TSO/GSO support where applicable or available
RX - raw and tapraw
TX - tap only (raw appears to be hitting a bug in the
af_packet family in the kernel resulting in it being
stuck in a -ENOBUFS loop.
This results in TX/RX TCP performance ~ 2-3 times higher
than qemu on same
From: Anton Ivanov
1. Provides infrastructure for vector IO using recvmmsg/sendmmsg.
1.1. Multi-message read.
1.2. Multi-message write.
1.3. Optimized queue support for multi-packet enqueue/dequeue.
1.4. BQL/DQL support.
2. Implements transports for several transports as well support
for direct
From: Anton Ivanov
1. Removes the need to walk the IRQ/Device list to determine
who triggered the IRQ.
2. Improves scalability (up to several times performance
improvement for cases with 10s of devices).
3. Improves UML baseline IO performance for one disk + one NIC
use case by up to 10%.
4
Patches 1 and 2 are the same as before, patch 3 adds TSO, GRO and
full scatter gather support as well as ability to on/off all
features from commandline and/or ethtool where applicable.
The result from patch 3 is 5.6Gbit on tcp throughput using the
tap/raw driver on a 3.5GHz AMD A4 desktop.
I am
5.26 Gbits/sec
A.
On 10/04/17 08:29, Anton Ivanov wrote:
I got the TSO and some offloads working for some (not all) cases of my
patchsets.
Preliminary speeds and feeds on iperf:
[ 4] local 192.168.98.1 port 5001 connected with 192.168.98.132 port
54838
[ 4] 0.0-10.0 sec 4.78 GBytes 4.11
From: Anton Ivanov
1. Provides infrastructure for vector IO using recvmmsg/sendmmsg.
1.1. Multi-message read.
1.2. Multi-message write.
1.3. Optimized queue support for multi-packet enqueue/dequeue.
1.4. BQL/DQL support.
2. Implements transports for several transports as well support
for direct
This update cleans up the code and simplifies the xmit routines to
share some of the code. It also brings tap up to date to do scatter
gather and TSO on transmit. The result is ... drum roll... 4.5Gbit+
on iperf on my laptop. As a reference QEMU+kvm with all bells and
whistles does under 1GBit and
From: Anton Ivanov
1. Removes the need to walk the IRQ/Device list to determine
who triggered the IRQ.
2. Improves scalability (up to several times performance
improvement for cases with 10s of devices).
3. Improves UML baseline IO performance for one disk + one NIC
use case by up to 10%.
4
I got the TSO and some offloads working for some (not all) cases of my
patchsets.
Preliminary speeds and feeds on iperf:
[ 4] local 192.168.98.1 port 5001 connected with 192.168.98.132 port 54838
[ 4] 0.0-10.0 sec 4.78 GBytes 4.11 Gbits/sec
As a comparison - kvm/qemu on same machine does
From: Anton Ivanov
1. Provides infrastructure for vector IO using recvmmsg/sendmmsg.
1.1. Multi-message read.
1.2. Multi-message write.
1.3. Optimized queue support for multi-packet enqueue/dequeue.
1.4. BQL/DQL support.
2. Implements transports for several transports as well support
for direct
Hi List, hi Richard,
I found a logical error in the SG code. This revision fixes that. No
other changes - the rest appears to work as it should in my testing.
Brgds,
A.
--
Check out the vibrant tech community on one of
From: Anton Ivanov
1. Removes the need to walk the IRQ/Device list to determine
who triggered the IRQ.
2. Improves scalability (up to several times performance
improvement for cases with 10s of devices).
3. Improves UML baseline IO performance for one disk + one NIC
use case by up to 10%.
4
Hi Richard, hi list,
Attached is an updated and rebased versus 4.13 patchset for the
Epoll based IRQ controller and Vector Network driver.
I have been running a backport to OpenWRT/kernel 4.4 since around
May and I have not found any bugs so far. It appears stable and
performs up to 3-4 times bet
From: Anton Ivanov
1. Provides infrastructure for vector IO using recvmmsg/sendmmsg.
1.1. Multi-message read.
1.2. Multi-message write.
1.3. Optimized queue support for multi-packet enqueue/dequeue.
1.4. BQL/DQL support.
2. Implements transports for several transports as well support
for direct
From: Anton Ivanov
1. Removes the need to walk the IRQ/Device list to determine
who triggered the IRQ.
2. Improves scalability (up to several times performance
improvement for cases with 10s of devices).
3. Improves UML baseline IO performance for one disk + one NIC
use case by up to 10%.
4
From: Anton Ivanov
1. Provides infrastructure for vector IO using recvmmsg/sendmmsg.
1.1. Multi-message read.
1.2. Multi-message write.
1.3. Optimized queue support for multi-packet enqueue/dequeue.
1.4. BQL/DQL support.
2. Implements transports for several transports as well support
for direct
From: Anton Ivanov
1. Removes the need to walk the IRQ/Device list to determine
who triggered the IRQ.
2. Improves scalability (up to several times performance
improvement for cases with 10s of devices).
3. Improves UML baseline IO performance for one disk + one NIC
use case by up to 10%.
4
From: Anton Ivanov
Adds scatter gather support to the vector network drivers.
Provides additional 55% performance improvement for most
network applications running in the UML instance.
Signed-off-by: Anton Ivanov
---
arch/um/drivers/vector_kern.c | 63
Hi List,
The following is a set of patches which cleans up and finally
stabilizes the work I did a couple of years ago while at Cisco.
1. The IRQ handling improves significantly and now allows large
numbers of devices without incurring penalties to look up "who
spoke". IRQ is now edge driven - fu
Am I right that this may be a route to avoid the full munmap we have presently
upon exec or I am missing something. If that is the case it will be well worth
it.
On 13 May 2017 11:24:04 GMT+01:00, Thomas Meyer wrote:
>Am 13.05.2017 um 12:04 schrieb Richard Weinberger:
>> Thomas,
>
>Hi,
>
>> On
A.
Forwarded Message
Subject: DQL and TCQ_F_CAN_BYPASS destroy performance under
virtualizaiton (Was: "Re: net_sched strange in 4.11")
Date: Tue, 9 May 2017 08:46:46 +0100
From: Anton Ivanov
Organization: Cambridge Greys Limited
To: David S. Miller
So far it is late 2.6. The high res timer subsystem settled fully
somewhere circa 2.6.10 if memory serves me right. One of those lovely
kernels which had VM collapse bugs :)
I am finishing testing the vector IO drivers and epoll irq controller
for them you will need 3.0 onwards
In fact, I have
Have a look at the list archive, this was covered a couple of weeks ago.
I believe Richard is working on a fix.
A.
On 07/05/17 21:06, Thomas Meyer wrote:
> Hi,
>
> with the current rw/linux-next I see a lot of those:
>
> Mai 07 22:01:34 bifrst kernel: [ cut here ]
> Mai 0
On 17/03/17 17:33, Richard Weinberger wrote:
> Am 17.03.2017 um 18:04 schrieb Anton Ivanov:
>> On 17/03/17 16:56, Richard Weinberger wrote:
>>> Anton,
>>>
>>> On Fri, Mar 17, 2017 at 8:51 AM, Anton Ivanov
>>> wrote:
>>>> Hi list, hi Richard
On 17/03/17 17:04, Anton Ivanov wrote:
> On 17/03/17 16:56, Richard Weinberger wrote:
>> Anton,
>>
>> On Fri, Mar 17, 2017 at 8:51 AM, Anton Ivanov
>> wrote:
>>> Hi list, hi Richard
>>>
>>> There is an extra check in mm/mmap.c which now throw
On 17/03/17 16:56, Richard Weinberger wrote:
> Anton,
>
> On Fri, Mar 17, 2017 at 8:51 AM, Anton Ivanov
> wrote:
>> Hi list, hi Richard
>>
>> There is an extra check in mm/mmap.c which now throws a WARN on every
>> page in making UML unusable with the latest
Hi Richard, hi list,
I finally figured out what was going wrong with my Epoll IRQ controller POC.
I have a working one now. I will submit it after I have done some more
extensive tests on it.
So far it is showing 10-20% improvements in IO in default config (one
Ethernet, one UBD). This should
Hi list, hi Richard
There is an extra check in mm/mmap.c which now throws a WARN on every
page in making UML unusable with the latest 4.11-rc2
A.
--
Check out the vibrant tech community on one of the world's most
engag
From: Anton Ivanov
UBD at present is extremely slow because it handles only
one request at a time in the IO thread and IRQ handler.
The single request at a time is replaced by handling multiple
requests as well as necessary workarounds for short reads/writes.
Resulting performance improvement
On 09/11/16 16:08, James McMechan wrote:
> Hi
>
> I am not clear on the remainder/remainder_size would not a single offset
> parameter work? rather than copying it off and back?
Possible.
The other alternative is to copy the remainder (if it exists) to the
beginning of the buffer at the end o
From: Anton Ivanov
UBD at present is extremely slow because it handles only
one request at a time in the IO thread and IRQ handler.
The single request at a time is replaced by handling multiple
requests as well as necessary workarounds for short reads/writes.
Resulting performance improvement
mot.co.uk wrote:
>> From: Anton Ivanov
>>
>> UBD at present is extremely slow because it handles only
>> one request at a time in the IO thread and IRQ handler.
>>
>> The single request at a time is replaced by handling multiple
>> requests as w
ff with on raw read, 17% on find /usr -exec cat {}
A.
On 29/09/16 21:36, anton.iva...@kot-begemot.co.uk wrote:
> From: Anton Ivanov
>
> UBD at present is extremely slow because it handles only
> one request at a time in the IO thread and IRQ handler.
>
> The single request at a
From: Anton Ivanov
UBD at present is extremely slow because it handles only
one request at a time in the IO thread and IRQ handler.
The single request at a time is replaced by handling multiple
requests as well as necessary workarounds for short reads/writes.
Resulting performance improvement
From: Anton Ivanov
UBD at present is extremely slow because it handles only
one request at a time in the IO thread and IRQ handler.
The single request at a time is replaced by handling multiple
requests as well as necessary workarounds for short reads/writes.
Resulting performance improvement
Hi Richard, hi list.
I had some difficulties evaluating the actual performance
difference because of the strange behaviour with the ubd speed
reduction over time (as per my earlier "There is something rotten"
email).
Overall, if I take the only the first few dd runs to read the
entire disk and co
Hi Richard, hi list,
I got around to devote some time to my patchsets and while working on my
ubd block read one, I observed the following behaviour with stock 4.8.0-rc7
On a freshly booted image, stock 4.8.0-rc7, Debian jessie userspace:
root@wyvern-uml:~# while true; do dd if=/dev/ubda of=/dev
I have some patches which bring network performance to > 3gbit for a single
core virtual router/firewall/net device, need to find time to get them up to
date and resubmit.
Some disk is improvements too.
On 20 July 2016 19:04:28 CEST, Ritesh Raj Sarraf wrote:
>-BEGIN PGP SIGNED MESSAGE-
On 08/07/16 21:03, Артём Литвинович wrote:
> Greetings.
>
> Apparently, ubd is too slow for practical use.
> I'm getting 0.8 Mb/s write speed, while hostfs does 25 Mb/s (and on
> the host itself it's similar).
> This is rather frustrating for such a great project as UML is, and i'd
> like to try fi
On 21/05/16 13:11, Andrea Gelmini wrote:
> Signed-off-by: Andrea Gelmini
> ---
> arch/um/os-Linux/time.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/um/os-Linux/time.c b/arch/um/os-Linux/time.c
> index 0e39b99..6caa556 100644
> --- a/arch/um/os-Linux/time.c
> +
On 10/02/16 14:35, Richard Weinberger wrote:
> Am 10.02.2016 um 15:29 schrieb Vegard Nossum:
>> USB has not been usable on UML since this commit:
>>
>> commit e25df1205f37c7bff3ab14fdfc8a5249f3c69c82
>> Author: Martin Schwidefsky
>> Date: Thu May 10 15:45:57 2007 +0200
>>
>> [S390] Kconfig:
her primitive - no ring buffers, primitive
>> guaranteed flush and guaranteed to-record-size read.
>>
>> Signed-off-by: Anton Ivanov
>> ---
>> arch/um/drivers/ubd.h | 2 +
>> arch/um/drivers/ubd_kern.c | 156
>> arch/
On 10/01/16 16:00, Richard Weinberger wrote:
> On Mon, Dec 21, 2015 at 8:04 PM, Anton Ivanov
> wrote:
>> Hi list, hi Richard,
>>
>> This rather primitive patchset pushes disk IO by ~ 15%.
>>
>> dd to /dev/null on a host memory cached 16G sparse disk image with
in one go, I'd rather submit it in
chunks so it is easier to review even if this will result in patch churn
(the whole do_safe_read malarkey will bite the bullet once part 2 is out).
A.
On 21/12/15 18:54, Anton Ivanov wrote:
> This patch adds support for merging notifications on the ubd
&
-size read.
Signed-off-by: Anton Ivanov
---
arch/um/drivers/ubd.h | 2 +
arch/um/drivers/ubd_kern.c | 156
arch/um/drivers/ubd_user.c | 19 +-
arch/um/include/shared/os.h | 1 +
arch/um/os-Linux/file.c | 12
5 files changed, 161
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
Patch in your queue, current code looks OK.
I will try to assemble the full ubd acceleration sequence of patches
this afternoon to submit that as well.
A.
On 11/12/15 18:38, Richard Weinberger wrote:
> Am 11.12.2015 um 12:24 schrieb Anton Ivanov:
>> On 11/12/15 08:16, Richard Weinber
by checking if there is a timer
interrupt in-flight before processing any pending timer interrupts.
Signed-off-by: Anton Ivanov
---
arch/um/os-Linux/signal.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/um/os-Linux/signal.c b/arch/um/os-Linux/signal.c
hardirq.h by setting
__ARCH_IRQ_EXIT_IRQS_DISABLED
This patch adds this to UML where due to the way IRQs are handled
it is an optimization (it works fine without it too).
Signed-off-by: Anton Ivanov
---
arch/um/include/asm/hardirq.h | 23 +++
1 file changed, 23 insertions(+)
create
On 11/12/15 18:38, Richard Weinberger wrote:
> Am 11.12.2015 um 12:24 schrieb Anton Ivanov:
>> On 11/12/15 08:16, Richard Weinberger wrote:
>>> Am 11.12.2015 um 07:58 schrieb Anton Ivanov:
>>>>>> 2. I cannot catch what is wrong with the current code in signal
On 11/12/15 08:16, Richard Weinberger wrote:
> Am 11.12.2015 um 07:58 schrieb Anton Ivanov:
>>>> 2. I cannot catch what is wrong with the current code in signal.c. When
>>>> I read it, it should not produce re-entrancy. But it does.
>>> Sorry for the delay. Unti
On 10/12/15 22:40, Richard Weinberger wrote:
> On Fri, Nov 20, 2015 at 1:05 PM, Anton Ivanov
> wrote:
>> I have gotten to the bottom of this.
>>
>> 1. The IRQ handler re-entrancy issue predates the timer patch. Adding a
>> simple guard with a WARN_ON_ONCE
On 07/12/15 07:24, st...@nixia.no wrote:
> Den 2015-12-06 16:34, skrev Vegard Nossum:
>> Hi,
>>
>> I've been running into some odd crashes when starting my UML instance
>> from Python. This is my script:
>>
>> import subprocess
>> subprocess.check_call(['path/to/vmlinux', 'mem=2048M',
>> 'rootfstyp
On 27/11/15 09:59, Richard Weinberger wrote:
> Hi!
>
> Am 26.11.2015 um 10:49 schrieb Anton Ivanov:
>> Hi List, hi Richard,
>>
>> While working on the EPOLL I managed to consistently reproduce and get down
>> to the bottom of the process in D state bug which you
Hi List, hi Richard,
While working on the EPOLL I managed to consistently reproduce and get
down to the bottom of the process in D state bug which you occasionally
see with UML. I recall asking Richard's help on this for the first time
nearly 5 years ago ;-).
It is extremely rare with the POLL
the revised
EPOLL IRQ controller patch (as an incremental on top of the errata).
The Epoll controller with the fixes still manages ~ 10%+ better
performance than the old POLL based one and it will also allow further
optimizations later on.
A.
On 20/11/15 12:05, Anton Ivanov wrote:
> I h
On 23/11/15 22:24, Richard Weinberger wrote:
> On Fri, Nov 20, 2015 at 7:47 PM, Anton Ivanov
> wrote:
>> Hi list, hi Richard.
>>
>> Have you had time to review this one? I think it is not contentious - it
>> is something QEMU has been doing for a very long time now.
for-linus-4.4-rc1
>
> for you to fetch changes up to
> 2eb5f31bc4ea24bb293e82934cfa1cce9573304b:
>
> um: Switch clocksource to hrtimers (2015-11-06 22:54:49 +0100)
>
>
> This pull request includes the following UM
the transactions. This is dangerous if you end up in a reentrant
situation.
A.
On 08/11/15 15:20, Anton Ivanov wrote:
> This decreases the number of syscalls per read/write by half.
>
> Signed-off-by: Anton Ivanov
> ---
> arch/um/drivers/ubd_kern.c | 27 +---
This one came up with a messed up formatting, I will resubmit at some
point (hopefully as we refine this).
A.
On 20/11/15 16:45, Anton Ivanov wrote:
> The signals should be restored to their pre-off state
> not turned on.
>
> Signed-off-by: Anton Ivanov
> ---
> arch/um/ker
Fix signal handling to use store/restore instead of block/unblock
as that may cause IRQ reentrancy
Signed-off-by: Anton Ivanov
---
arch/um/os-Linux/skas/process.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux
The signals should be restored to their pre-off state
not turned on.
Signed-off-by: Anton Ivanov
---
arch/um/kernel/skas/mmu.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/um/kernel/skas/mmu.c b/arch/um/kernel/skas/mmu.c
index 9591a66..a845de6 100644
--- a/arch
Fixes: IRQ Reentrancy
The code in signal.c used in irq controller emulation does not
prevent IRQ reentrancy which can result in all types of issues
as IRQs including ones on the same device can be executed in
a nested manner
Signed-off-by: Anton Ivanov
---
arch/um/kernel/irq.c | 8
1 - 100 of 233 matches
Mail list logo
