linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Crystal Wood <swood@redhat.com>
To: John Kacur <jkacur@redhat.com>
Cc: Clark Williams <williams@redhat.com>,
	rt-users <linux-rt-users@vger.kernel.org>,
	Peter Xu <peterx@redhat.com>
Subject: Re: [PATCH] oslat: Add command line option for bucket width
Date: Tue, 13 Dec 2022 16:21:42 -0600	[thread overview]
Message-ID: <8842ea476d3e003bfc4659b1b79fd3fe97a67950.camel@redhat.com> (raw)
In-Reply-To: <71d7762e-720-fa73-96de-2e922b371e@redhat.com>

On Tue, 2022-12-13 at 14:31 -0500, John Kacur wrote:
> 
> 
> On Fri, 9 Dec 2022, Crystal Wood wrote:
> 
> > On Fri, 2022-12-09 at 20:03 -0500, John Kacur wrote:
> > 
> > > A quick first look through and run, see the one comment above
> > > near "case 'W'"
> > > 
> > > and then
> > > 
> > > checkpatch reports some minor easily fixed problems
> > > 
> > > ../linux/scripts/checkpatch.pl oslat.patch 
> > > ERROR: code indent should use tabs where possible
> > > #100: FILE: src/oslat/oslat.c:342:
> > > +^I^I          g.precision, us);$
> > > 
> > > ERROR: code indent should use tabs where possible
> > > #102: FILE: src/oslat/oslat.c:344:
> > > +^I^I         g.precision, us);$
> > 
> > I was matching the existing style in the file that tended to use spaces
> > for
> > alignment.
> 
> Hmmn, when I run checkpatch on the file I don't get any other warnings 
> about spaces, or when I look in vim I see tabs, maybe check your editor?
> Please fix the above when you submit a version two

I see it in a lot of the structure definitions and macros; looks like
checkpatch only cares if it's part of the whitespace at the beginning of a
line (which is not necessarily the same as indentation, but whatever).  I'll
change it since you asked (it wasn't clear from the docs that checkpatch.pl
is the applicable style guide), but barring specific style guides or
pushback I tend to default to being kind to people using different tab
widths, having been one in a past life before the kernel beat it out of me.
:-)

> > > ERROR: spaces required around that '=' (ctx:VxV)
> > > #227: FILE: src/oslat/oslat.c:654:
> > > +       OPT_BUCKETSIZE=1, OPT_BUCKETWIDTH, OPT_CPU_LIST, 
> > > OPT_CPU_MAIN_THREAD,
> > >                       ^
> > 
> > I only added OPT_BUCKETWIDTH to the list; I didn't touch the =1 part.
> 
> Yup, you're right, we're not as strict about the formatting in rt-tests as
> the kernel is, and sure it will catch stuff that isn't strictly your fault
> but I do normally run checkpatch on the patches. If you want to throw in 
> the spaces around the '=' in your patch I'd appreciate it.

Sure.  As an aside, I do think that's a rule that is usually helpful but can
harm readability in some circumstances when applied strictly (e.g. "2*x + 1"
looks better to me than "2 * x + 1" which doesn't emphasize the order of
operations and doesn't provide the eye with as much structure).

> Now to the more important stuff, I like your patch, but I have a few 
> questions.
> 
> What if the user specifies a bucket-width greater than 1000?
> Is it meaningful to to have a bucket-width of 2000 for example?

Yes, that works and could be useful if you're trying to focus on larger
latency sources.

> If we have a bucket width of 1500, then we are going to have 
> the same precision as if we specified 500?

Anything that isn't a multiple of 1000 will give you nanosecond precision.

-Crystal


  reply	other threads:[~2022-12-13 22:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-09  5:22 [PATCH] oslat: Add command line option for bucket width Crystal Wood
2022-12-10  1:03 ` John Kacur
2022-12-10  1:40   ` Crystal Wood
2022-12-13 19:31     ` John Kacur
2022-12-13 22:21       ` Crystal Wood [this message]
2022-12-13 20:41     ` John Kacur
2022-12-13 20:46       ` John Kacur
2022-12-13 22:24       ` Crystal Wood

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=8842ea476d3e003bfc4659b1b79fd3fe97a67950.camel@redhat.com \
    --to=swood@redhat.com \
    --cc=jkacur@redhat.com \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=peterx@redhat.com \
    --cc=williams@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).