Message-ID: <1440736322.32300.122.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 21:32:02 -0700
In-Reply-To: <20150827224304.918.qmail@ns.horizon.com>
References: <20150827224304.918.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: 2119
Lines: 47

On Thu, 2015-08-27 at 18:43 -0400, George Spelvin wrote:
> Jason Low wrote:
> > 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.
> 
> Don't worry, I'm not offended.  I just started editing and figured
> I might as well share it.
> 
> Whichever solution is easier.  My only complaint about bitmapped variables
> is that so many are "unsigned long" because the Linux atomic access
> primitives, originally designed for file system bitmaps, use that type.
> 
> But using that for a non array wastes 4 bytes on 64-bit platforms that
> can't be used if the code is to work on 32-bit ones.
> 
> >> 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.
> 
> Will it?  I thought it got called on the running process only.
> Which is not the (blocked by assumption) process of interest.
> 
> I don't suspect that this would be a problem in practice, as CPU-time
> timers are used on activities which use a *lot* of it.  But it
> seemed like a flaw worth either acknowledging or disproving.

You're right, this is only called on running processes. If the process
is blocked, sending the signal can get delayed. However, in practice,
this is not really a problem as you mentioned. Also, this "issue" is
also not really avoidable even without this patch. For instance, a timer
may expire and the process can get block before the next scheduler
interrupt.

Thanks,
Jason

--
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/