search for: reacquir

...t; On Wed, Jul 13, 2016 at 12:39 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >> Interesting. I'm not sure this is the right metric, however. There are >> lots of analyses that hold pointers to other analyses but don't need to. >> The analysis handle itself can be reacquired lazily if we care to do so. >> > > Are you thinking of instead holding a pointer to the analysis manager? > I'm really concerned with using this approach as the common case. It triggers the run of the analyses at very strange points (mid-query of some other analysis) and force...

Hello, Does Samba server have a grace period that allows a client to reopen its files and reacquire locks on them before the locks are given to other clients? If there is no grace period, is there a way for the client to avoid the lock ownerships files if the connection goes away for a short period (say few seconds). Thanks and Regards Sudheer

...analyses just for a "recalculate" step seems to be the > exceptional case (only 3/28 or about 10%) Interesting. I'm not sure this is the right metric, however. There are lots of analyses that hold pointers to other analyses but don't need to. The analysis handle itself can be reacquired lazily if we care to do so. What's truly problematic is holding pointers into another analysis's data structures. To be concrete, holding a pointer to ScalarEvolution is not a fundamental problem because we could make the analysis reacquire the pointer at the start of every query. Holding...

Hi, I've got a box with CentOS 4.2 x86_64 which had no DHCP access for a few hours, now I can't ping it (I'm pretty sure the box is still up). I expect the DHCP lease has timed out and the box has lost it's IP, I was expecting it to reacquire it once the DHCP came back up (configuration problem) - but no luck. Is this a known problem? Any solution/workaround? (for now or for the future...) Cheers, MaZe.

...list 1. If a lockres is found to be in use, dlm_run_purgelist keeps trying to purge the same lockres instead of trying the next lockres. 2. When a lockres is found unused, dlm_run_purgelist releases lockres spinlock before setting DLM_LOCK_RES_DROPPING_REF and calls dlm_purge_lockres. spinlock is reacquired but in this window lockres can get reused. This leads to BUG. This patch modifies dlm_run_purgelist to skip lockres if it's in use and purge next lockres. It also sets DLM_LOCK_RES_DROPPING_REF before releasing the lockres spinlock protecting it from getting reused. Signed-off-by: Srinivas...

...ed, Jul 13, 2016 at 12:39 AM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote: > Interesting. I'm not sure this is the right metric, however. There are lots of analyses that hold pointers to other analyses but don't need to. The analysis handle itself can be reacquired lazily if we care to do so. > > Are you thinking of instead holding a pointer to the analysis manager? > > I'm really concerned with using this approach as the common case. It triggers the run of the analyses at very strange points (mid-query of some other analysis) and forces u...

In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before calling nouveau_dmem_chunk_alloc(). Reacquire the lock before continuing to the next page. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- I found this while testing Jason Gunthorpe's hmm tree but this is independant of those changes. I guess it could go through David Airlie's tree for nouveau or Jason's tree....

I see that lots of improvements have happened in cross configure support compared to version 3.8p1 but a couple of problems remain 1) The check that openpty does not reacquire controlling terminal (line 1326 in configure.ac) does not have a default value - I ran the test on my target and checked it was OK but I'm not sure what is the best default for others. 2) The etc_default_login check at line 2973 in configure.ac attempts to define a default behaviour but c...

...ting to an FXO card and two SIP UAs connecting to asterisk locally. I have configured extensions.conf such that dialing 9 on the SIP phones allows me to dial an outbound number via the FXO interface . Works fine. What's not working is that pressing 9 should causes either GS BT-100 phone to reacquire a dialtone since I have placed ignorepat => 9 in the config file. Any ideas? rgds burak

...07 jqpublic after a few minutes running the command whoami and crontab fails and looking at the home directory shows the userid number as opposed to the usernames drwxr-xr-x 2 16785470 16777729 4.0K Mar 27 2007 jdoe drwxr-xr-x 5 16785433 16777729 4.0K Jun 2 10:27 jqpublic running getent will reacquire the usernames allowing whoami to work again. Any help is appreciated.

...disadvantage is that all threads have to wait if some thread doesn't want to release the read lock in a timely manner. The hard part will be analyzing loops in the generated IR to decide whether a call to pulse the lock needs to be inserted in the loop body or not. Obviously, dropping and reacquiring a lock is expensive, so if the loop is provably short, I don't want to do that. So it sounds like I should be passing the pointer to the stack root list at the same time I release the lock? I supposed I could store it in the TLD which I guess wouldn't be too expensive. > Walking t...

...own by 544.29 us (-57%) and the total wait time decreased by 69%. This shows that the virtqueue kick is indeed hogging the lock. The patched version actually has higher contention than the unmodified version. I think the reason for this is that each virtqueue kick now includes a short release and reacquire. This short release gives other vcpus a chance to acquire the lock and progress, hence more contention but overall better wait time numbers. name acq-bounces acquisitions holdtime-min holdtime-max holdtime-total unmodified 10771 5038346 0.00 3271.81 59016905.47 patc...

...own by 544.29 us (-57%) and the total wait time decreased by 69%. This shows that the virtqueue kick is indeed hogging the lock. The patched version actually has higher contention than the unmodified version. I think the reason for this is that each virtqueue kick now includes a short release and reacquire. This short release gives other vcpus a chance to acquire the lock and progress, hence more contention but overall better wait time numbers. name acq-bounces acquisitions holdtime-min holdtime-max holdtime-total unmodified 10771 5038346 0.00 3271.81 59016905.47 patc...

Hello, I have been looking at the Ruby/EventMachine. First let me say it look very good. Reactor model with no threads makes for fast reliable server, and I have read about marvelous Twisted framework for Python and am glad to see something similar for Ruby. I am writing network app with Ruby threads now and it very slow, and I try new Ruby 1.9 with native threads that make it much slower.

On Thu, Jun 13, 2019 at 05:11:21PM -0700, Ralph Campbell wrote: > In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before > calling nouveau_dmem_chunk_alloc(). > Reacquire the lock before continuing to the next page. > > Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> > --- > > I found this while testing Jason Gunthorpe's hmm tree but this is > independant of those changes. I guess it could go through > David Airlie's tre...

On 6/13/19 5:11 PM, Ralph Campbell wrote: > In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before > calling nouveau_dmem_chunk_alloc(). > Reacquire the lock before continuing to the next page. > > Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> > --- > > I found this while testing Jason Gunthorpe's hmm tree but this is > independant of those changes. I guess it could go through > David Airlie's tre...

...virtio_blk during the guest->host notify operation (which occasionally could take a long time so we don't want to keep holding the queue_lock). Imagine that the request completes just after virtqueue_notify() and this virtio_blk device is being hot unplugged. If hot unplug completes before reacquiring the queue_lock and leaving this function the result is a use-after-free of queue_lock. diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 774c31d..d674977 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -199,8 +199,14 @@ static void do_virtblk...

...virtio_blk during the guest->host notify operation (which occasionally could take a long time so we don't want to keep holding the queue_lock). Imagine that the request completes just after virtqueue_notify() and this virtio_blk device is being hot unplugged. If hot unplug completes before reacquiring the queue_lock and leaving this function the result is a use-after-free of queue_lock. diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 774c31d..d674977 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -199,8 +199,14 @@ static void do_virtblk...

...the new one produced by the device for all open files instead. * FUSE_OPENDIR -> fh (dirp_map) Same story as for FUSE_OPEN but for open directories. * FUSE_GETLK/SETLK/SETLKW -> (inode->posix_locks and fcntl(F_OFD_GET/SETLK)) The session contains file locks. The driver must reacquire them upon restore. It's unclear what to do when locking fails. Live migration has the same problem since the FUSE session will be moved to a new virtio-fs device instance. It makes sense to tackle both features together. This is something that can be implemented in the next year, but it...

Hello all, I'm reposting this to the libvirt-users list: I looked around for documentation on intra-host KVM migration but haven't found much. For example, this could be useful to "migrate" VM to run on an upgraded version of `qemu-kvm` without migrating to a different host and migrating back. We tested migrating a VM to the same host on an old version of libvirt (el7), and