On Tue, 2015-10-20 at 02:18 +0200, Frederic Weisbecker wrote:
> This way we might consume less space in the signal struct (well,
> depending on bool size or padding) and we don't need to worry about
> ordering between the running and checking_timers fields.
This looks fine to me. I ended up going with booleans since I thought
that makes the code more readable, but this method would be okay too.
I do have 1 question below.
> +/* struct thread_group_cputimer::state bits */
> +#define CPUTIMER_STATE_RUNNING 1
> +#define CPUTIMER_STATE_CHECKING 2
> +
> /**
> * struct thread_group_cputimer - thread group interval timer counts
> * @cputime_atomic: atomic thread group interval timers.
> - * @running: true when there are timers running and
> - * @cputime_atomic receives updates.
> - * @checking_timer: true when a thread in the group is in the
> - * process of checking for thread group timers.
> - *
> + * @state: flags describing the current state of the cputimer.
> + * CPUTIMER_STATE_RUNNING bit means the timers is elapsing.
> + * CPUTIMER_STATE_CHECKING bit means that the cputimer has
> + * expired and a thread in the group is checking the
> + * callback list.
> * This structure contains the version of task_cputime, above, that is
> * used for thread group CPU timer calculations.
> */
> struct thread_group_cputimer {
> - struct task_cputime_atomic cputime_atomic;
> - bool running;
> - bool checking_timer;
> + struct task_cputime_atomic cputime_atomic;
> + unsigned int state;
Here are we actually increasing the overhead from 2 bytes -> 4 bytes? If
we want to use less space, I was thinking 'unsigned char'.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
