headers
Jed Davis | 1 Mar 2006 01:01
Picon
Favicon

Re: Strange numbers from gettimeofday(2)

YAMAMOTO Takashi <yamt <at> mwd.biglobe.ne.jp> writes:

>> Hum, at last for Xen3, tsc_timestamp is updated just before the context
>> switch, so it should be OK. Xen2 looks similar.
>
> iirc, xen2 does rdtsc in its timer interrupt handler
> and stores it to a global variable, and uses it for any domains.

I noticed, in xen2's start-of-day code (arch/x86/smpboot.c), a
procedure that attempts to get all the CPUs TSCs as synchronized as
possible; the comments indicate an assumption that they'll run at the
same rate thereafter.

--

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))
Permalink | Reply | 0 comments |
headers
Johan Ihren | 1 Mar 2006 02:46

Re: xen network issues


Hi Manuel,

>> * 100% interrupt rate
>> * oodles of "sip0: FIFO ring overrun" on one server
>> * "fxp0: device timeout" on the other server
>> * oodles of "nfs_timer: ignoring error 64" on all domUs
>>
>> What I did *not* find was any massive network traffic. I.e. no raging
>> storms that I could see.
>
> Hi,
> how old are your dom0 and domU kernels ? An issue have been fixed  
> recently
> (virtual interfaces not checking the ethernet addresses in packets)
> which could cause the kind of issue you're seeing.
> The fix has been pulled up to the netbsd-3 and netbsd-3-0 branches.

All kernels were original 3.0 machines, only modified to allow the  
dom0s to deal with larger numbers of vnd devices, i.e. without that  
fix (that I had not noticed).

I will rebuild and see if I can trigger this again. However, as I've  
had zero trouble in all my prior testing I guess I will not easily  
verify if this was indeed my problem, but will have to wait until the  
next time I have live students (nothing beats students for finding  
problems). I will let you know whether that works out or if I end up  
in trouble again...

But I agree the (fixed) problem sounds like a plausible explanation
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jed Davis | 1 Mar 2006 05:12
Picon
Favicon

xen_microtime() revisited

I've attached a patch that changes the microtime function used under
Xen from cc_microtime to a xen_microtime that's actually useful -- it
extrapolates from the last step made by hardclock(9) by combining the
Xen system_time "left over" after the last call to hardclock(9) with
the CPU counter difference from when the system_time was last updated.

This works out to be a lot like cc_microtime, except that it uses
Xen's idea of the CPU frequency instead of trying to measure it using
the clock interrupt -- which latter, since the "clock interrupt" here
might be delivered with a certain amount of jitter even in
non-degenerate cases, seems like a bad idea.

There is also a check to keep the clock from going backwards by
clamping the returned time; this applies for only backsteps of <1s,
because (as the accompanying XXX comment states) I haven't attempted
to specifically exempt administrative settimeofday use, and also out
of general paranoia (i.e., something I haven't thought of goes wrong,
and then the clock spends a few hours stopped, and I find out the hard
way the next morning).  This will be triggered in the case where the
time(9) clock speed is reduced, e.g. by the start or end of an
adjtime(2) adjustment; the extrapolation overshoots what hardclock(9)
actually does at the end of that tick, and so winds up a few
microseconds fast just that once.  (For the rest of the adjustment,
it's fine.)  This could probably be handled more elegantly.

The XEN_CLOCK_DEBUG define may of course be removed if one doesn't
want to get a printf whenever the above check is triggered.

This may not be even remotely correct as far as MP is concerned.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hubert Feyrer | 1 Mar 2006 14:16
Picon
Favicon

reducing XENU kernel config maintenance


Is there a good reason not to define XENU in terms of the XEN0 kernel 
config? Comparing the two configs, how about the following? (I understand 
that this may leave in all the pci drivers... some change for config(8) to 
do that properly may be needed).

The reason to do something like this would be to reduce maintenance costs 
and avoid errors (and defining XEN0 in terms of a GENERIC kernel would be 
nice, too, in turn).

Open questions:
  * is options WSDISPLAY_SCROLLSUPPORT left out in XENU on purpose, or was
     XENU just not updated (see "avoid errors")
  * should wd*, sd*, cd* at hypervisor be enabled?
  * A comment on what 'xenevt' is would be nice in XEN0

  - Hubert
    Department Against Redundancy Department

#	$NetBSD$
#
# XENU kernel, defined in terms of XEN0
#
include "arch/i386/conf/XEN0"

no options 	DOM0OPS
no options 	WSDISPLAY_SCROLLSUPPORT		# is that on purpose?

xennet* 	at hypervisor?		# Xen virtual network interface
(Continue reading)

Permalink | Reply | 5 comments |
headers
Quentin Garnier | 1 Mar 2006 14:26

Re: reducing XENU kernel config maintenance

On Wed, Mar 01, 2006 at 02:16:34PM +0100, Hubert Feyrer wrote:
> 
> Is there a good reason not to define XENU in terms of the XEN0 kernel 
> config? Comparing the two configs, how about the following? (I understand 
> that this may leave in all the pci drivers... some change for config(8) to 
> do that properly may be needed).

That's config(1), and it already does the right thing in this case.

> The reason to do something like this would be to reduce maintenance costs 
> and avoid errors (and defining XEN0 in terms of a GENERIC kernel would be 
> nice, too, in turn).
> 
> Open questions:
>  * is options WSDISPLAY_SCROLLSUPPORT left out in XENU on purpose, or was
>     XENU just not updated (see "avoid errors")
>  * should wd*, sd*, cd* at hypervisor be enabled?
>  * A comment on what 'xenevt' is would be nice in XEN0
> 
> 
>  - Hubert
>    Department Against Redundancy Department
> 
> 
> #	$NetBSD$
> #
> # XENU kernel, defined in terms of XEN0
> #
> include "arch/i386/conf/XEN0"
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg Troxel | 1 Mar 2006 15:39
Picon

Re: reducing XENU kernel config maintenance

I think this is really a symptom of the more general config file
maintenance issue.  Lots of things don't relate to hardware and should
probably be in INCLUDE.net INCLUDE.fs and so on, factoring out common
code, leaving the files people use having mostly includes and perhaps
'no eisa'

I don't find XEN0 and XENU to be particularly similar - I find GENERIC
and XEN0 to be similar, and XENU to have almost no hardware support.

--

-- 
        Greg Troxel <gdt <at> ir.bbn.com>
Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 1 Mar 2006 15:58

Re: reducing XENU kernel config maintenance

On Wed, Mar 01, 2006 at 02:16:34PM +0100, Hubert Feyrer wrote:
> 
> Is there a good reason not to define XENU in terms of the XEN0 kernel 
> config? Comparing the two configs, how about the following? (I understand 
> that this may leave in all the pci drivers... some change for config(8) to 
> do that properly may be needed).

I don't like much nested includes like this. It makes it much harder to
know what is or is not in a config.

> 
> The reason to do something like this would be to reduce maintenance costs 
> and avoid errors (and defining XEN0 in terms of a GENERIC kernel would be 
> nice, too, in turn).

I think what we want it more kernel config fragments (e.g. GENERIC.pci,
GENERIC.fs, GENERIC.network and so on) to be inclued in real config files,
not one config file including one other.

If we go this way I think it would be better to have XEN0 include XENU and not
the opposite. There would be less things to remove.

> 
> Open questions:
>  * is options WSDISPLAY_SCROLLSUPPORT left out in XENU on purpose, or was
>     XENU just not updated (see "avoid errors")

The error is to have WSDISPLAY_* options in XENU. There's no wscons in XenU.

>  * should wd*, sd*, cd* at hypervisor be enabled?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Quentin Garnier | 1 Mar 2006 16:03

Re: reducing XENU kernel config maintenance

On Wed, Mar 01, 2006 at 03:58:31PM +0100, Manuel Bouyer wrote:
[...]
> >  * A comment on what 'xenevt' is would be nice in XEN0
> 
> "required for xentools20" ? :)

Then it should go to std.xen0 or something.

--

-- 
Quentin Garnier - cube <at> cubidou.net - cube <at> NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.
Permalink | Reply | 1 comment |
headers
Manuel Bouyer | 1 Mar 2006 16:07

Re: reducing XENU kernel config maintenance

On Wed, Mar 01, 2006 at 04:03:48PM +0100, Quentin Garnier wrote:
> On Wed, Mar 01, 2006 at 03:58:31PM +0100, Manuel Bouyer wrote:
> [...]
> > >  * A comment on what 'xenevt' is would be nice in XEN0
> > 
> > "required for xentools20" ? :)
> 
> Then it should go to std.xen0 or something.

But we don't have such a file, and I'm not sure it's worth it for a single
config file.

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--
Permalink | Reply | 0 comments |
headers
Thor Lancelot Simon | 1 Mar 2006 21:19

BUFQ_FCFS for XENU kernels?

I *think* requests passing through xbd will always be sorted by the
underlying device driver in the dom0 OS.  Certainly if the requests
are heading for something like a vnd, sorting them in the domU kernel
is not the right thing to do, since they could then be sorted *three*
times.

But I cannot build a domU kernel (on the 3.0) branch with "options BUFQ_FCFS"
defined.  The other BUFQ options seem to work (READPRIO, PRIOCSCAN) but FCFS
produces a compile-time error in xbd.  I do not quite see why.

Does xbd already default to BUFQ_FCFS?  We should either make it so or
make BUFQ_FCFS the default with "options BUFQ_FCFS" in the XENU kernel.

Certainly vnd itself should default to BUFQ_FCFS.  Ultimately, in a stack
of NetBSD domU on NetBSD dom0, with xbd and vnd in the middle, only the
actual lowest-layer disk driver should sort.

--

-- 
  Thor Lancelot Simon	                                     tls <at> rek.tjls.com

  "We cannot usually in social life pursue a single value or a single moral
   aim, untroubled by the need to compromise with others."      - H.L.A. Hart
Permalink | Reply | 0 comments |

Gmane