All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2] [RFC] pselect01: Tune thresholds
Date: Mon, 15 May 2017 06:03:50 -0400 (EDT)	[thread overview]
Message-ID: <495691788.11461692.1494842630946.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20170512141658.26810-1-chrubis@suse.cz>



----- Original Message -----
> +
> +/*
> + * The threshold per one syscall is computed as a sum of:
> + *
> + *  250 us                 - accomodates for context switches, etc.
> + *  2*monotonic_resolution - accomodates for granurality of the
> CLOCK_MONOTONIC
> + *  slack_per_scall        - 0.1% of the sleep capped on 100ms
> + *                           which is slack allowed in kernel
> + *
> + * We also allow for outliners, i.e. add some number to the threshold in
> case
> + * that the number of iteration is small. For large enoung number of
> iterations
> + * outliners are averaged out.
> + */
> +static int compute_threshold(long long requested_us, unsigned int
> iterations)
> +{
> +	unsigned int slack_per_scall = MIN(100000, requested_us / 1000);

Hi,

while looking at fs/select.c I noticed that it also takes
current->timer_slack_ns into account and uses that if 
slack is smaller. Would it make sense to add ...?
  slack_per_scall = MAX(slack_per_scall, prctl(PR_GET_TIMERSLACK) / 1000);
The default is 50us, so maybe the 250us in formula covers this already?

v2 looks good to me, and my KVM guest ran test successfully for hours.

Regards,
Jan

> +
> +	return (250 + 2 * monotonic_resolution + slack_per_scall) * iterations
> +		+ (iterations > 1 ? 0 : 1500);
> +}
> +

  reply	other threads:[~2017-05-15 10:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-12 14:16 [LTP] [PATCH v2] [RFC] pselect01: Tune thresholds Cyril Hrubis
2017-05-15 10:03 ` Jan Stancek [this message]
2017-05-15 10:20   ` Xiao Yang
2017-05-15 13:15     ` Jan Stancek
2017-05-15 13:23       ` Cyril Hrubis
2017-05-15 12:36   ` Cyril Hrubis
2017-05-15 13:00     ` Jan Stancek
2017-05-15 13:13       ` Cyril Hrubis
2017-05-15 13:16         ` Jan Stancek
2017-05-22  8:39         ` Jan Stancek
2017-05-22 12:04           ` Cyril Hrubis
2017-05-22 13:37             ` Jan Stancek
2017-05-22 13:19           ` Cyril Hrubis
2017-05-22 14:57             ` Jan Stancek
2017-05-22 15:15               ` Cyril Hrubis
2017-05-23  7:54                 ` Jan Stancek
2017-05-23  9:16                   ` Cyril Hrubis
2017-05-23  9:45                     ` Jan Stancek
2017-06-02 12:48                       ` Jan Stancek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=495691788.11461692.1494842630946.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.