Accción requerida de su parte
Para completar el proceso de desuscripciC3n a nuestros newsletters siga este enlace: http://www.publimailer.com.ar/publimail/box.php?nl=3&p=0&s=3f69f4ce1602816f8ede80a086467247&funcml=cunsub
Re: fdisk.8 - updated disklabel example
On 11/18/10 15:56, Jason McIntyre wrote: > On Thu, Nov 18, 2010 at 10:15:17AM +0100, Alexander Hall wrote: >> >> Indeed. >> >> $ grep PAGER .profile >> export PAGER="/usr/bin/less -i" >> >> Should one really want to do a case-sensitive all-lowercase search, just >> type '-i' in less (yes, _in_ less, not on any command line) to toggle that. >> > > actually, less(1) is better designed than that: you can set whatever > options you like for it using the LESS environment variable. so for example, > i use LESS=FiR. ah... ~/.profile "fixed" now... > and you don;t need to type -i from within less: if your search term > contains uppercase letters, it will turn case insensitivity off. that > covers most cases. Yes, I was specifically talking about a "case-sensitive all-lowercase search" above. :-) /Alexander > > jmc
Computadoras Armadas - Diseño - Gamers - Hogar - Oficina y mas..
[IMAGE][IMAGE][IMAGE][IMAGE][IMAGE][IMAGE][IMAGE][IMAGE]En caso de no querer recibir mas este correo por favor presione AQUI .
Re: fdisk.8 - updated disklabel example
On Thu, Nov 18, 2010 at 10:15:17AM +0100, Alexander Hall wrote: > > Indeed. > > $ grep PAGER .profile > export PAGER="/usr/bin/less -i" > > Should one really want to do a case-sensitive all-lowercase search, just > type '-i' in less (yes, _in_ less, not on any command line) to toggle that. > actually, less(1) is better designed than that: you can set whatever options you like for it using the LESS environment variable. so for example, i use LESS=FiR. and you don;t need to type -i from within less: if your search term contains uppercase letters, it will turn case insensitivity off. that covers most cases. jmc
Nuova apertura
HOBBY CANTINA inaugura il nuovo sito web. www.hobbycantina.it dedicato alla vendita online di prodotti, articoli e attrezzatura per VINO, BIRRA, OLIO, DISTILLATI, ACETO e SUCCHI DI FRUTTA. Ti invitiamo a conoscere tutti i prodotti e le offerte che abbiamo preparato per te! Per te uno SCONTO DEL 10%, fino al 31 dicembre 2010, su tutti gli articoli o servizi. Per saperne di piy e per essere contattati - clicca qui-. Per cancellarti dalla mailing list e non ricevere altre nostre news - clicca qui -. Per ricevere ancora news di HOBBY CANTINA - clicca qui-. Informativa per il trattamento dei dati personali legge 196/2003 (codice privacy) I Vs dati personali sono stati raccolti dai seguenti elenchi pubblici: - www.infoimprese.it costituito da INFOCAMERE Spa e - www.paginegialle.it costituito dal gruppo Seat Pagine Gialle spa e www.google.com. Il trattamento degli stessi sar` gestito in modo esclusivo dalla ditta scrivente e nel piy completo e totale rispetto del Codice della Privacy. Qualora non desideriate ricevere in futuro comunicazioni dalla ditta scrivente, potete opporVi esercitando i diritti previsti dall'art. 7 del codice della privacy inviando un messaggio di posta elettronica all'indirizzo mittente, indicando gli indirizzi da cancellare. Potete altresl cliccare sul link in calce. Cancellami --- Questa e-mail h stata spedita a tech@openbsd.org perchh h stato registrato a una nostra mailing list (lista di indirizzi e-mail), o prelevato da elenchi pubblici. In qualsiasi momento se si vuole cancellare o esercitare i suoi diritti, lo pur fare visitando: http://utente05.serversmtp.net/admin/public/unsubscribe.php?g=53&addr=t...@openbsd.org
Re: iostat and more than one core
On Thu, Nov 18, 2010 at 14:42 +0100, Mike Belopuhov wrote: > On Thu, Nov 18, 2010 at 01:01 -0500, Ted Unangst wrote: > > 2010/11/17 Mike Belopuhov : > > > I think this time around it's kernel that's wrong. top(1) calls CPTIME2 > > > when 'ncpus > 1' to get detailed per-cpu information. CPTIME is only > > > valid on UP systems, but can represent an average value on MP without > > > having userland programs figure out whether kernel is lying or not. > > > > I think the patch below is reasonable, and probably the best idea. > > > > But what really puzzles me is why are iostat and friends using CP_TIME > > as a clock? That strikes me as rather weird. > > > > they don't. they're using hz as clock. cp_time field description in > src/usr.bin/vmstat/dkstats.h is a bit misleading. funny enough, their calculations are still a bit off: they devide by hz, meaning that this CPTIME values are collected in 1/hz intervals, while in practice they're collected by the statclock, which is called from hardclock only if stathz is zero. Otherwise they're called 1/stathz times per second, where stathz can be 128Hz :)
Re: iostat and more than one core
On Wed, Nov 17, 2010 at 23:00 -0500, Luis Useche wrote:
> > I think this time around it's kernel that's wrong. top(1) calls CPTIME2
> > when 'ncpus > 1' to get detailed per-cpu information. CPTIME is only
> > valid on UP systems, but can represent an average value on MP without
> > having userland programs figure out whether kernel is lying or not.
> >
> Yes, I figured that perhaps this error could be on some other userland
> program. In this case is probably better to change the kernel instead.
>
> Regarding your previous patch, the kernel can also return the information of
> the primary cpu only:
>
this diff is not correct as it doesn't take other cpus in account.
the CPUSTATES values tell us how many ticks cpu spent where (in userland,
in kernel, was idle or was servicing interrupts).
so if dd is running on cpu1, you won't account for that.
> diff --git a/sys/kern/kern_sysctl.c b/sys/kern/kern_sysctl.c
> index 4973cf6..4b49ad1 100644
> --- a/sys/kern/kern_sysctl.c
> +++ b/sys/kern/kern_sysctl.c
> @@ -454,16 +454,12 @@ kern_sysctl(int *name, u_int namelen, void *oldp,
> size_t *oldlenp, void *newp,
> newp, newlen, p));
> case KERN_CPTIME:
> {
> - CPU_INFO_ITERATOR cii;
> - struct cpu_info *ci;
> int i;
>
> bzero(cp_time, sizeof(cp_time));
>
> - CPU_INFO_FOREACH(cii, ci) {
> - for (i = 0; i < CPUSTATES; i++)
> - cp_time[i] +=
> ci->ci_schedstate.spc_cp_time[i];
> - }
> + for (i = 0; i < CPUSTATES; i++)
> + cp_time[i] +=
> cpu_info_primary.ci_schedstate.spc_cp_time[i];
>
> return (sysctl_rdstruct(oldp, oldlenp, newp, &cp_time,
> sizeof(cp_time)));
>
> Luis.
Re: iostat and more than one core
On Thu, Nov 18, 2010 at 01:01 -0500, Ted Unangst wrote: > 2010/11/17 Mike Belopuhov : > > I think this time around it's kernel that's wrong. top(1) calls CPTIME2 > > when 'ncpus > 1' to get detailed per-cpu information. CPTIME is only > > valid on UP systems, but can represent an average value on MP without > > having userland programs figure out whether kernel is lying or not. > > I think the patch below is reasonable, and probably the best idea. > > But what really puzzles me is why are iostat and friends using CP_TIME > as a clock? That strikes me as rather weird. > they don't. they're using hz as clock. cp_time field description in src/usr.bin/vmstat/dkstats.h is a bit misleading.
Re: fdisk.8 - updated disklabel example
On 11/18/10 08:06, Jason McIntyre wrote: > On Thu, Nov 18, 2010 at 12:40:21AM +0100, roberth wrote: added uid and removed rpm. being a historical snapshot in time and all, i left the rest as is. or would a completely new example along the lines of the old one be more welcome? >>> >>> we could update it more if there's potentially stuff missing. is >>> there? >> >> missing: >>boundstart: >>boundend: >> >> havent seen for some time: >> interleave: 1 >> trackskew: 0 >> cylinderskew: 0 >> headswitch: 0 # microseconds >> track-to-track seek: 0 # microseconds >> > > oh right. so it would be good to update that too. > btw, searching for "uid" (as in the disklabel output) in the disklabel manpage and only finding it as "UID" feels unintuitive. >>> >>> how else should you search for "uid"? we are currently using >>> "disklabel UID", which i think is fine. >> >> s1 looking at the output of disklabel sees "uid: something". >> personally that leads me to search for "uid" not "UID". >> "man -k uid" leads to disktab.5, but not everyone will read through the >> whole disklabel manpage first, guess i am too spoiled by the manpage >> quality on OpenBSD to expect this. >> (a lot of ppl wont be following the commit porn on source-changes...) >> > > so you mean the case sensitivity thing. there's not much we can do about > that - "uid" would be inconsistent within the documentation (though not > neccessarily wrong). i guess if you have case sensitive searching on, > you need to be aware of it. note that for man pages, the case > insensitive option of less(1) (-i) works very nicely (you can turn it > off just by typing an uppercase letter). at least when searching man > pages, i never find case sensitivity helpful. Indeed. $ grep PAGER .profile export PAGER="/usr/bin/less -i" Should one really want to do a case-sensitive all-lowercase search, just type '-i' in less (yes, _in_ less, not on any command line) to toggle that. /Alexander > >> >> krw would like to see my idea of a "whole new example", so i'll do >> that later today. replacing the shebang with output from -current on >> recent hardware in one go might make more sense. >> >> - Robert > > great! > jmc
