Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?

2009-09-18 Thread James Carlson
Darren Reed wrote:
 Guys, In most parts of the source code, the zoneid is unsigned,
 except for where we use ALL_ZONES. Then in some places,
 we assign or expect -1 to be the zoneid, for example in what
 psh prints and expects to see.
 
 It would seem that we want the zoneid to be unsigned except
 for when its value is -1. This seems... like it could lead to
 confusion or other bad things.

It looks to me like it's neither signed nor unsigned, but rather an
opaque type.  It supports only equality tests, not general arithmetic
ones, so signedness doesn't seem to come into it.

What kind of confusion are you expecting?

-- 
James Carlson 42.703N 71.076W carls...@workingcode.com
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] Per-zone CPU Usage Reporting?

2009-09-18 Thread Hernan Saltiel
Hello, Jeff!
Have you tried prstat -Z? Is this not what you are looking for?
Best regards,

HeCSa.
http://www.aosug.com.ar

On Fri, Sep 18, 2009 at 10:27 AM, Jeff Victor jeff.j.vic...@gmail.comwrote:

 Has anyone written a tool to provide per-zone reporting of CPU usage -
 that can be shared? I know someone who wants to do this.

 Thanks in advance,
 --JeffV
 ___
 zones-discuss mailing list
 zones-discuss@opensolaris.org




-- 
HeCSa
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] Per-zone CPU Usage Reporting?

2009-09-18 Thread Mike Gerdts
On Fri, Sep 18, 2009 at 8:30 AM, Mads Toftum m...@toftum.dk wrote:
 On Fri, Sep 18, 2009 at 09:27:54AM -0400, Jeff Victor wrote:
 Has anyone written a tool to provide per-zone reporting of CPU usage -
 that can be shared? I know someone who wants to do this.

 There's http://asyd.net/home/projects/zonestats

 vh

 Mads Toftum

The approach used there and by prstat -Z will miss all short-running
programs.  If you don't have many short running processes, this is not
a big deal.  However, if you have a print server, software builds, and
sometimes misbehaving applications, such approaches miss the bulk of
the workload.

I've solved this, but in code I sadly can't share.  All the info
needed to recreate it is linked from:

http://www.opensolaris.org/jive/thread.jspa?threadID=82217#306092

-- 
Mike Gerdts
http://mgerdts.blogspot.com/
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] Per-zone CPU Usage Reporting?

2009-09-18 Thread Jeff Victor
Hernan,

In addition to Mike's point about short-lived processes, prstat
doesn't tell me how much CPU time a process used during its life.
Solaris Accounting will generate a record for each process, showing
how much CPU time it used, and which zone it was in. If you collect
all of the records, you can sum CPU time for each zone.

They need a tool which uses those records for input and generates a
report for chargeback.

--JeffV

On Fri, Sep 18, 2009 at 9:31 AM, Hernan Saltiel hsalt...@gmail.com wrote:
 Hello, Jeff!
 Have you tried prstat -Z? Is this not what you are looking for?
 Best regards,

 HeCSa.
 http://www.aosug.com.ar

 On Fri, Sep 18, 2009 at 10:27 AM, Jeff Victor jeff.j.vic...@gmail.com
 wrote:

 Has anyone written a tool to provide per-zone reporting of CPU usage -
 that can be shared? I know someone who wants to do this.

 Thanks in advance,
 --JeffV
 ___
 zones-discuss mailing list
 zones-discuss@opensolaris.org



 --
 HeCSa




-- 
--JeffV
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] Per-zone CPU Usage Reporting?

2009-09-18 Thread Hernan Saltiel
That's right, there is a key term here, and is reporting, which involves
accounting.
Thanks, Jeff!
Best regards,

HeCSa.



On Fri, Sep 18, 2009 at 1:48 PM, Jeff Victor jeff.j.vic...@gmail.comwrote:

 Hernan,

 In addition to Mike's point about short-lived processes, prstat
 doesn't tell me how much CPU time a process used during its life.
 Solaris Accounting will generate a record for each process, showing
 how much CPU time it used, and which zone it was in. If you collect
 all of the records, you can sum CPU time for each zone.

 They need a tool which uses those records for input and generates a
 report for chargeback.

 --JeffV

 On Fri, Sep 18, 2009 at 9:31 AM, Hernan Saltiel hsalt...@gmail.com
 wrote:
  Hello, Jeff!
  Have you tried prstat -Z? Is this not what you are looking for?
  Best regards,
 
  HeCSa.
  http://www.aosug.com.ar
 
  On Fri, Sep 18, 2009 at 10:27 AM, Jeff Victor jeff.j.vic...@gmail.com
  wrote:
 
  Has anyone written a tool to provide per-zone reporting of CPU usage -
  that can be shared? I know someone who wants to do this.
 
  Thanks in advance,
  --JeffV
  ___
  zones-discuss mailing list
  zones-discuss@opensolaris.org
 
 
 
  --
  HeCSa
 



 --
 --JeffV




-- 
HeCSa
___
zones-discuss mailing list
zones-discuss@opensolaris.org

Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?

2009-09-18 Thread James Carlson
Darren Reed wrote:
 James Carlson wrote:
 What kind of confusion are you expecting?
   
 
 If it is an opaque type, then how does it get printed?

You have to use one of the look-up functions to convert it to a string
for printing.  Zones are named, not numbered, even in the kernel.

This was a key architectural decision made by (I think) Andy Tucker back
when Kevlar was being designed.  I wanted zoneids to be like UIDs, GIDs,
and other UNIX IDs -- used as small integers everywhere, and converted
to names when necessary by use of name services.  Andy and the other
kernel folks disagreed, and felt that strings were better, and integers
would be allocated on the fly (non-permanently) and never used as zone
identifiers, except in performance-sensitive (and entirely internal)
contexts.

 As an unsigned integer for all values, except -1, or as a signed integer?

I still think it's properly neither.  Users can't reasonably do
anything with those ephemeral numbers, so printing them (or using them
in user interfaces) would be a mistake.

-- 
James Carlson 42.703N 71.076W carls...@workingcode.com
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?

2009-09-18 Thread James Carlson
Darren Reed wrote:
 On 18/09/09 10:44 AM, James Carlson wrote:
 Darren Reed wrote:
 As an unsigned integer for all values, except -1, or as a signed integer?
 

 I still think it's properly neither.  Users can't reasonably do
 anything with those ephemeral numbers, so printing them (or using them
 in user interfaces) would be a mistake.
   
 
 Do a man snoop and search for the word zone.

My argument wasn't that there were zero bugs in the OS.  That keyword
seems to me to be pretty clearly a defect in snoop.  (And apparently a
recent one; less than a year old.)

It was that the zone IDs are inherently ephemeral, and were designed to
be that way.  They're not intended as any sort of administrative
interface.  The kernel assigns them arbitrarily as the zones are
booting, and there's no guarantee at all that any particular number
represents any zone over time.  At best, they're useful in undocumented
or volatile debug interfaces (such as in mdb).

It's the zone names that are fixed and are intended as administrative
interfaces.

And that since you can't do any reasonable arithmetic comparisons
between them (what does it mean for one zone ID to be less than
another?), it doesn't really matter what a zoneid_t is inside.

-- 
James Carlson 42.703N 71.076W carls...@workingcode.com
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?

2009-09-18 Thread James Carlson
John Leser wrote:
 Darren Reed wrote:
 Do a man snoop and search for the word zone.

 
 Oh, that was a bit of a let-down...
 
 Anyway, this seems to pose an interesting challenge to programs like
 snoop that want to encode zone ID information in output files.  The zone
 ID numbers are essentially meaningless in a disk file - who knows what
 zone names they corresponded to at the time the capture was done.  To be
 at all correct, IPNET headers have to encode the string literal for the
 zone name.   Ugly.

Not necessarily ... it's ok if IPNET headers have zone IDs in them, as
long as all the tools that use them translate to and from string format
when interacting with the user or transporting them externally (as in
over a network or via a file).  (I think you're right, though, that
ideally the interface between kernel and user space should deal with
strings, because there's no guarantee that a given zone ID that you see
in an IPNET header will necessarily correspond to the named zone you get
moments later with getzonenamebyid() -- because the ID might have been
discarded by the kernel between those two events.)

Yes, it does mean that some file formats are going to be a little less
pretty than others.

 Also, zone IDs are more ephemeral than UIDs or GIDs, because if I log
 out and back in, I keep the same UID.   If I halt and boot the same
 zone, it gets a new zone ID each time.

Exactly.  It's a different design.  As I said before, when I was working
on the old Kevlar team, I wanted a UID-like experience for these,
because I _assumed_ that people would want to administer zone names
centrally across many machines, and because it seemed to me that
integers would be easier to encode and work with.  The rest of the team,
though, assumed differently: that if there was any coordination between
machines, it would be on the basis of the assigned zone name, and that
strings were just as easy to use.

-- 
James Carlson 42.703N 71.076W carls...@workingcode.com
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] [networking-discuss] is the zoneid signed or unsigned?

2009-09-18 Thread Peter Memishian

   Do a man snoop and search for the word zone.
  
  My argument wasn't that there were zero bugs in the OS.  That keyword
  seems to me to be pretty clearly a defect in snoop.  (And apparently a
  recent one; less than a year old.)

... and indeed, there's a CR open to allow snoop to accept zone names.

--
meem
___
zones-discuss mailing list
zones-discuss@opensolaris.org