From: Paul Jackson <pj@sgi.com>
To: Shailabh Nagar <nagar@watson.ibm.com>
Cc: akpm@osdl.org, Valdis.Kletnieks@vt.edu, jlan@engr.sgi.com,
balbir@in.ibm.com, csturtiv@sgi.com,
linux-kernel@vger.kernel.org, hadi@cyberus.ca,
netdev@vger.kernel.org
Subject: Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats
Date: Tue, 4 Jul 2006 12:59:09 -0700 [thread overview]
Message-ID: <20060704125909.1265fadc.pj@sgi.com> (raw)
In-Reply-To: <44A9B1A9.20106@watson.ibm.com>
Shailabh wrote:
> Perhaps I should use the the other ascii format for specifying cpumasks
> since its more amenable
> to specifying an upper bound for the length of the ascii string and is
> more compact ?
Eh - basically - I don't have a strong opinion either way.
I have a slight esthetic preference toward using list of ranges format
from shell scripts and shell prompts, and using the 32-bit hex words
from C code:
17-26,44-47 # shell - list of ranges
0000f000,07fe0000 # C - 32-bit hex words
Since the primary interface you are working with is C code, that would
mean I'd slightly prefer the 32-bit hex word variant.
>From what I've seen neither of the reasons you gave for preferring
the 32-bit hex word format are persuasive (even though they both
lead to the same conclusion as I preferred ;):
Which is more compact depends on that particular bit pattern
you need to represent. See for example the examples above.
The lack of a perfect upper bound on the list of ranges format
is a theoretical problem that I have never seen in practice.
Only pathological constructs exceed six ascii characters per
set bit.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
next prev parent reply other threads:[~2006-07-04 19:59 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <44892610.6040001@watson.ibm.com>
[not found] ` <20060609042129.ae97018c.akpm@osdl.org>
[not found] ` <4489EE7C.3080007@watson.ibm.com>
[not found] ` <449999D1.7000403@engr.sgi.com>
[not found] ` <44999A98.8030406@engr.sgi.com>
[not found] ` <44999F5A.2080809@watson.ibm.com>
[not found] ` <4499D7CD.1020303@engr.sgi.com>
[not found] ` <449C2181.6000007@watson.ibm.com>
[not found] ` <20060623141926.b28a5fc0.akpm@osdl.org>
[not found] ` <449C6620.1020203@engr.sgi.com>
[not found] ` <20060623164743.c894c314.akpm@osdl.org>
[not found] ` <449CAA78.4080902@watson.ibm.com>
[not found] ` <20060623213912.96056b02.akpm@osdl.org>
[not found] ` <449CD4B3.8020300@watson.ibm.com>
[not found] ` <44A01A50.1050403@sgi.com>
[not found] ` <20060626105548.edef4c64.akpm@osdl.org>
[not found] ` <44A020CD.30903@watson.ibm.com>
[not found] ` <20060626111249.7aece36e.akpm@osdl.org>
[not found] ` <44A026ED.8080903@sgi.com>
[not found] ` <20060626113959.839d72bc.akpm@osdl.org>
[not found] ` <44A2F50D.8030306@engr.sgi.com>
[not found] ` <20060628145341.529a61ab.akpm@osdl.org>
[not found] ` <44A2FC72.9090407@engr.sgi.com>
[not found] ` <20060629014050.d3bf0be4.pj@sgi.com>
[not found] ` <200606291230.k5TCUg45030710@turing-police.cc.vt.edu>
[not found] ` <200606291230.k5TCUg45030710@turing-police.cc.vt. edu>
[not found] ` <20060629094408.360ac157.pj@sgi.com>
[not found] ` <20060629110107.2e56310b.akpm@osdl.org>
2006-06-29 19:10 ` [Patch][RFC] Disabling per-tgid stats on task exit in taskstats Shailabh Nagar
2006-06-29 19:23 ` Paul Jackson
2006-06-29 19:33 ` Andrew Morton
2006-06-29 19:43 ` Shailabh Nagar
2006-06-29 20:00 ` Andrew Morton
2006-06-29 22:13 ` Shailabh Nagar
2006-06-29 23:00 ` jamal
2006-06-29 20:01 ` Shailabh Nagar
2006-06-29 21:22 ` Paul Jackson
2006-06-29 22:54 ` jamal
2006-06-30 0:38 ` Shailabh Nagar
2006-06-30 1:05 ` Andrew Morton
2006-06-30 1:11 ` Shailabh Nagar
2006-06-30 1:30 ` jamal
2006-06-30 3:01 ` Shailabh Nagar
2006-06-30 12:45 ` jamal
2006-06-30 2:25 ` Paul Jackson
2006-06-30 2:35 ` Andrew Morton
2006-06-30 2:43 ` Paul Jackson
2006-06-30 18:53 ` Shailabh Nagar
2006-06-30 19:10 ` Shailabh Nagar
2006-06-30 19:19 ` Shailabh Nagar
2006-06-30 20:19 ` jamal
2006-06-30 22:50 ` Andrew Morton
2006-07-01 2:20 ` Shailabh Nagar
2006-07-01 2:43 ` Andrew Morton
2006-07-01 3:37 ` Shailabh Nagar
2006-07-01 3:51 ` Andrew Morton
2006-07-03 21:11 ` Shailabh Nagar
2006-07-03 21:41 ` Andrew Morton
2006-07-04 0:13 ` Shailabh Nagar
2006-07-04 0:38 ` Andrew Morton
2006-07-04 20:19 ` Paul Jackson
2006-07-04 20:22 ` Paul Jackson
2006-07-04 0:54 ` Shailabh Nagar
2006-07-04 1:01 ` Andrew Morton
2006-07-04 13:05 ` jamal
2006-07-04 15:18 ` Shailabh Nagar
2006-07-04 16:37 ` Shailabh Nagar
2006-07-04 19:24 ` jamal
2006-07-05 14:09 ` Shailabh Nagar
2006-07-05 20:25 ` Chris Sturtivant
2006-07-05 20:32 ` Shailabh Nagar
2006-07-03 4:53 ` Paul Jackson
2006-07-03 15:02 ` Shailabh Nagar
2006-07-03 15:55 ` Paul Jackson
2006-07-03 16:31 ` Paul Jackson
2006-07-04 0:09 ` Shailabh Nagar
2006-07-04 19:59 ` Paul Jackson [this message]
2006-07-05 17:20 ` Jay Lan
2006-07-05 18:18 ` Shailabh Nagar
2006-06-30 22:56 ` Andrew Morton
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=20060704125909.1265fadc.pj@sgi.com \
--to=pj@sgi.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@osdl.org \
--cc=balbir@in.ibm.com \
--cc=csturtiv@sgi.com \
--cc=hadi@cyberus.ca \
--cc=jlan@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nagar@watson.ibm.com \
--cc=netdev@vger.kernel.org \
/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).