Date: 27 Aug 2015 18:43:04 -0400
Message-ID: <20150827224304.918.qmail@ns.horizon.com>
From: "George Spelvin" <linux@horizon.com>
To: jason.low2@hp.com, linux@horizon.com
Subject: Re: [PATCH 3/3] timer: Reduce unnecessary sighand lock contention
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <1440712555.32300.112.camel@j-VirtualBox>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1624
Lines: 35

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