search for: locklessly

Every now and then I get an alert like this one. I have no clue what this "rear" subsystem is, or why madam would be trying to write to its log file. Can anyone enlighten me? thanks in advance! ------------------------- SELinux is preventing /usr/sbin/mdadm from write access on the file /var/log/rear/rear-fcshome.log.lockless. ***** Plugin restorecon (93.9 confidence) suggests

On Thu, Mar 30, 2017 at 10:16:15AM +0800, Jason Wang wrote: > > > On 2017?03?29? 20:07, Michael S. Tsirkin wrote: > > On Tue, Mar 21, 2017 at 12:04:47PM +0800, Jason Wang wrote: > > > For the socket that exports its skb array, we can use lockless polling > > > to avoid touching spinlock during busy polling. > > > > > > Signed-off-by: Jason Wang

On Thu, Mar 30, 2017 at 10:16:15AM +0800, Jason Wang wrote: > > > On 2017?03?29? 20:07, Michael S. Tsirkin wrote: > > On Tue, Mar 21, 2017 at 12:04:47PM +0800, Jason Wang wrote: > > > For the socket that exports its skb array, we can use lockless polling > > > to avoid touching spinlock during busy polling. > > > > > > Signed-off-by: Jason Wang

On Tue, Mar 21, 2017 at 12:04:47PM +0800, Jason Wang wrote: > For the socket that exports its skb array, we can use lockless polling > to avoid touching spinlock during busy polling. > > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > drivers/vhost/net.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git

On Tue, Mar 21, 2017 at 12:04:47PM +0800, Jason Wang wrote: > For the socket that exports its skb array, we can use lockless polling > to avoid touching spinlock during busy polling. > > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > drivers/vhost/net.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git

For the socket that exports its skb array, we can use lockless polling to avoid touching spinlock during busy polling. Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/net.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 53f09f2..41153a3 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c

On 2017?03?29? 20:07, Michael S. Tsirkin wrote: > On Tue, Mar 21, 2017 at 12:04:47PM +0800, Jason Wang wrote: >> For the socket that exports its skb array, we can use lockless polling >> to avoid touching spinlock during busy polling. >> >> Signed-off-by: Jason Wang <jasowang at redhat.com> >> --- >> drivers/vhost/net.c | 7 +++++-- >> 1 file

Although Dovecot is already read-lockless and it uses only short- lived write locks, it's be really nice to just get rid of the locking completely. :) I just figured out that O_APPEND is pretty great. If the operating system updates seek position after writing to a file opened with O_APPEND, writes to Dovecot's transaction log file can be made lockless. I see that this works with

We use spinlock to synchronize the work list now which may cause unnecessary contentions. So this patch switch to use llist to remove this contention. Pktgen tests shows about 5% improvement: Before: ~1300000 pps After: ~1370000 pps Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/vhost/vhost.c | 52 +++++++++++++++++++++++++-------------------------- drivers/vhost/vhost.h |

On 04/26/2016 02:24 PM, Pankaj Gupta wrote: > Hi Jason, > > Overall patches look good. Just one doubt I have is below: >> We use spinlock to synchronize the work list now which may cause >> unnecessary contentions. So this patch switch to use llist to remove >> this contention. Pktgen tests shows about 5% improvement: >> >> Before: >> ~1300000 pps

Hi Jason, Overall patches look good. Just one doubt I have is below: > > We use spinlock to synchronize the work list now which may cause > unnecessary contentions. So this patch switch to use llist to remove > this contention. Pktgen tests shows about 5% improvement: > > Before: > ~1300000 pps > After: > ~1370000 pps > > Signed-off-by: Jason Wang <jasowang

Hi Jason, Overall patches look good. Just one doubt I have is below: > > We use spinlock to synchronize the work list now which may cause > unnecessary contentions. So this patch switch to use llist to remove > this contention. Pktgen tests shows about 5% improvement: > > Before: > ~1300000 pps > After: > ~1370000 pps > > Signed-off-by: Jason Wang <jasowang

Hi! I'm getting these frequently. several times I've done the steps listed there to suppress the messages, but I keep getting them. Anyone got a good idea how to deal with this? Thanks in advance! ---------------------------- SELinux is preventing mdadm from 'read, open' accesses on the file /var/log/rear/rear-fcshome.log.lockless. ***** Plugin restorecon (99.5 confidence)

http://dovecot.procontrol.fi/test/ I think I've fixed the problems that were corrupting indexes with the new code. It happened every time you had expunged some messages and new messages arrived. I think this release might actually work :) disable_plaintext_auth = yes will be default from now on. It allows plaintext authentication from localhost (127.*, ::1) however. I just figured out

Remove our (soon to be) bouncing email addresses, and update Dmitri's address. Dmitry will take over as maintainer for CAIF from now on. Cc: Vikram Arv <vikram.arv at stericsson.com> Cc: Dmitry Tarnyagin <dmitry.tarnyagin at stericsson.com> Cc: Dmitry Tarnyagin <dmitry.tarnyagin at lockless.no> Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> ---

Remove our (soon to be) bouncing email addresses, and update Dmitri's address. Dmitry will take over as maintainer for CAIF from now on. Cc: Vikram Arv <vikram.arv at stericsson.com> Cc: Dmitry Tarnyagin <dmitry.tarnyagin at stericsson.com> Cc: Dmitry Tarnyagin <dmitry.tarnyagin at lockless.no> Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> ---

How do you compile LLD? There's a big difference between when using MSVC vs Clang. The parallel ghash patch I was mentioning is almost 2x as fast when using Clang 7.0+ vs. MSVC 15.9+, I don't know exactly why. I also suggest you use the Release target. You should also grab this patch: https://reviews.llvm.org/D55056 - I had to revert it because it was causing issues with LLDB. But it

Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl(). This also makes the ioctl run lockless. v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 24 ++++++++++-------------- 1 file changed, 10

Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl(). This also makes the ioctl run lockless. v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 24 ++++++++++-------------- 1 file changed, 10

Leonardo, to answer to your questions, yes to all of them  You can take a look at this prototype/proposal: https://reviews.llvm.org/D55585 Overall, computing ghashes in parallel at link-time and merging Types with them is less costly that the current approach to merging. The 35sec you’re seeing for merging should go down to about 15sec. The patch doesn’t parallelize (yet) the Type merging