Message-ID: <1440712555.32300.112.camel@j-VirtualBox>
Subject: Re: [PATCH 3/3] timer: Reduce unnecessary sighand lock contention
From: Jason Low <jason.low2@hp.com>
To: George Spelvin <linux@horizon.com>
Cc: linux-kernel@vger.kernel.org, jason.low2@hp.com
Date: Thu, 27 Aug 2015 14:55:55 -0700
In-Reply-To: <20150827012828.9471.qmail@ns.horizon.com>
References: <20150827012828.9471.qmail@ns.horizon.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2038
Lines: 44

On Wed, 2015-08-26 at 21:28 -0400, George Spelvin wrote:
> > I can include your patch in the series and then use boolean for the new
> > checking_timer field. However, it looks like this applies on an old
> > kernel. For example, the spin_lock field has already been removed from
> > the structure.
> 
> Apologies; that was 4.1.6.  A 4.2-rc8 patch is appended (it's a pretty
> trivial merge once you look at it).

Frederic suggested that we just use a single "status" variable and
access the bits for the running and checking field. I am leaning towards
that method, so I might not include the rest of the boolean changes in
this patchset.

> > The spinlock call has already been removed from a previous patch. The
> > issue now is with contention with the sighand lock.
> 
> I'll look some more and try to wrap my head around it.
> 
> >> Or is it basically okay if this is massively racey, since process-wide
> >> CPU timers are inherently sloppy.  A race will just cause an expiration
> >> check to be missed, but it will be retried soon anyway.
> 
> > Yes, the worst case scenario is that we wait until the next thread to
> > come along and handle the next expired timer. However, this "delay"
> > already occurs now (for example: a timer can expire right after a thread
> > exits check_process_timers()).
> 
> Ad is this polled, or is there some non-polled system that will trigger
> another call to check_process_timers().
> 
> E.g. suppose a process fails to notice that it blew past a CPU time
> timeout before blocking.  Does anything guarantee that it will get
> the timeout signal in finite real time?

Yep, the check_process_timers will get called again during the next
scheduler interrupt (approximately after 1 jiffy) and send the signal if
it finds that the timer expired then.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/