On Thu, Aug 16, 2012 at 03:29:03PM -0400, J. Bruce Fields wrote:
> Looking back at this:
>
> - adding the sv_lock looks like the right thing to do anyway
> independent of containers, because svc_age_temp_xprts may
> still be running.
This is what I've been testing with.
Or
On Tue, Aug 21, 2012 at 01:28:00PM +0400, Stanislav Kinsbursky wrote:
> 20.08.2012 20:58, J. Bruce Fields пишет:
> >On Mon, Aug 20, 2012 at 07:11:00PM +0400, Stanislav Kinsbursky wrote:
> >>Currently, when you call kthread_create(), you add new job to
> >>kthreadd queue. Kthreadd is unique, starts
20.08.2012 20:58, J. Bruce Fields пишет:
On Mon, Aug 20, 2012 at 07:11:00PM +0400, Stanislav Kinsbursky wrote:
20.08.2012 18:56, J. Bruce Fields пишет:
On Mon, Aug 20, 2012 at 03:05:49PM +0400, Stanislav Kinsbursky wrote:
16.08.2012 23:29, J. Bruce Fields пишет:
Looking back at this:
20.08.2012 20:58, J. Bruce Fields пишет:
On Mon, Aug 20, 2012 at 07:11:00PM +0400, Stanislav Kinsbursky wrote:
20.08.2012 18:56, J. Bruce Fields пишет:
On Mon, Aug 20, 2012 at 03:05:49PM +0400, Stanislav Kinsbursky wrote:
16.08.2012 23:29, J. Bruce Fields пишет:
Looking back at this:
On Tue, Aug 21, 2012 at 01:28:00PM +0400, Stanislav Kinsbursky wrote:
20.08.2012 20:58, J. Bruce Fields пишет:
On Mon, Aug 20, 2012 at 07:11:00PM +0400, Stanislav Kinsbursky wrote:
Currently, when you call kthread_create(), you add new job to
kthreadd queue. Kthreadd is unique, starts right
On Thu, Aug 16, 2012 at 03:29:03PM -0400, J. Bruce Fields wrote:
Looking back at this:
- adding the sv_lock looks like the right thing to do anyway
independent of containers, because svc_age_temp_xprts may
still be running.
This is what I've been testing with.
Or
On Mon, Aug 20, 2012 at 07:11:00PM +0400, Stanislav Kinsbursky wrote:
> 20.08.2012 18:56, J. Bruce Fields пишет:
> >On Mon, Aug 20, 2012 at 03:05:49PM +0400, Stanislav Kinsbursky wrote:
> >>16.08.2012 23:29, J. Bruce Fields пишет:
> >>>Looking back at this:
> >>>
> >>> - adding the sv_lock looks
20.08.2012 18:56, J. Bruce Fields пишет:
On Mon, Aug 20, 2012 at 03:05:49PM +0400, Stanislav Kinsbursky wrote:
16.08.2012 23:29, J. Bruce Fields пишет:
Looking back at this:
- adding the sv_lock looks like the right thing to do anyway
independent of containers, because
On Mon, Aug 20, 2012 at 03:05:49PM +0400, Stanislav Kinsbursky wrote:
> 16.08.2012 23:29, J. Bruce Fields пишет:
> >Looking back at this:
> >
> > - adding the sv_lock looks like the right thing to do anyway
> > independent of containers, because svc_age_temp_xprts may
> > still be
16.08.2012 23:29, J. Bruce Fields пишет:
On Tue, Jul 24, 2012 at 03:40:37PM -0400, J. Bruce Fields wrote:
On Tue, Jul 03, 2012 at 04:58:57PM +0400, Stanislav Kinsbursky wrote:
v3:
1) rebased on 3.5-rc3 kernel.
v2: destruction of currently processing transport added:
1) Added marking of
16.08.2012 23:29, J. Bruce Fields пишет:
On Tue, Jul 24, 2012 at 03:40:37PM -0400, J. Bruce Fields wrote:
On Tue, Jul 03, 2012 at 04:58:57PM +0400, Stanislav Kinsbursky wrote:
v3:
1) rebased on 3.5-rc3 kernel.
v2: destruction of currently processing transport added:
1) Added marking of
On Mon, Aug 20, 2012 at 03:05:49PM +0400, Stanislav Kinsbursky wrote:
16.08.2012 23:29, J. Bruce Fields пишет:
Looking back at this:
- adding the sv_lock looks like the right thing to do anyway
independent of containers, because svc_age_temp_xprts may
still be running.
20.08.2012 18:56, J. Bruce Fields пишет:
On Mon, Aug 20, 2012 at 03:05:49PM +0400, Stanislav Kinsbursky wrote:
16.08.2012 23:29, J. Bruce Fields пишет:
Looking back at this:
- adding the sv_lock looks like the right thing to do anyway
independent of containers, because
On Mon, Aug 20, 2012 at 07:11:00PM +0400, Stanislav Kinsbursky wrote:
20.08.2012 18:56, J. Bruce Fields пишет:
On Mon, Aug 20, 2012 at 03:05:49PM +0400, Stanislav Kinsbursky wrote:
16.08.2012 23:29, J. Bruce Fields пишет:
Looking back at this:
- adding the sv_lock looks like the right
On Tue, Jul 24, 2012 at 03:40:37PM -0400, J. Bruce Fields wrote:
> On Tue, Jul 03, 2012 at 04:58:57PM +0400, Stanislav Kinsbursky wrote:
> > v3:
> > 1) rebased on 3.5-rc3 kernel.
> >
> > v2: destruction of currently processing transport added:
> > 1) Added marking of currently processing
On Tue, Jul 24, 2012 at 03:40:37PM -0400, J. Bruce Fields wrote:
On Tue, Jul 03, 2012 at 04:58:57PM +0400, Stanislav Kinsbursky wrote:
v3:
1) rebased on 3.5-rc3 kernel.
v2: destruction of currently processing transport added:
1) Added marking of currently processing transports with
On Tue, 24 Jul 2012 15:40:37 -0400 "J. Bruce Fields"
wrote:
> On Tue, Jul 03, 2012 at 04:58:57PM +0400, Stanislav Kinsbursky wrote:
> > v3:
> > 1) rebased on 3.5-rc3 kernel.
> >
> > v2: destruction of currently processing transport added:
> > 1) Added marking of currently processing transports
On Tue, 24 Jul 2012 15:40:37 -0400 J. Bruce Fields bfie...@fieldses.org
wrote:
On Tue, Jul 03, 2012 at 04:58:57PM +0400, Stanislav Kinsbursky wrote:
v3:
1) rebased on 3.5-rc3 kernel.
v2: destruction of currently processing transport added:
1) Added marking of currently processing
On Tue, Jul 03, 2012 at 04:58:57PM +0400, Stanislav Kinsbursky wrote:
> v3:
> 1) rebased on 3.5-rc3 kernel.
>
> v2: destruction of currently processing transport added:
> 1) Added marking of currently processing transports with XPT_CLOSE on per-net
> shutdown. These transports will be destroyed
On Tue, Jul 03, 2012 at 04:58:57PM +0400, Stanislav Kinsbursky wrote:
v3:
1) rebased on 3.5-rc3 kernel.
v2: destruction of currently processing transport added:
1) Added marking of currently processing transports with XPT_CLOSE on per-net
shutdown. These transports will be destroyed in
20 matches
Mail list logo