headers
Andriy Gapon | 1 Mar 2008 10:33
Picon

multiple filesystems sharing/clobbering device vnode


First, a little demonstration suggested by Bruce Evance:
[I hope you will continue reading after reboot]
1. mount_cd9660 /dev/acd0 /mnt1
2. mount -r /dev/acd0 /mnt2 # -r is important
3. ls -l /mnt1

The issue can be laconically described as follows:
1. We do not disallow multiple RO mounts of the same device (which could
be done either on purpose or by an accident).
2. All popular (on-disk) filesystems use/clobber bufobj of device's
vnode, even for RO mounts; some (ufs) do that even if mount fails.
3. There are no considerations for such a shared access, all filesystems
act as if it is an exclusive owner of the vnode / its bufobj.

Small snippet of code that speaks for itself (the most interesting lines
are marked with XXX at the beginning):
int
g_vfs_open(struct vnode *vp, struct g_consumer **cpp, const char
*fsname, int wr)
{
        struct g_geom *gp;
        struct g_provider *pp;
        struct g_consumer *cp;
        struct bufobj *bo;
        int vfslocked;
        int error;

        g_topology_assert();
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juergen Dankoweit | 2 Mar 2008 06:06
Picon
Favicon

PR 114597 and bug solving

Hello to the List,

in the next days I want to some debugging on the sym driver and the
communication with the cam layer. Where do I find some documentation how
the driver communicates with the cam layer, which parameters are needed
for the function calls and which return codes are generated?

Thank you very much for your help.

Best regards

J. Dankoweit

_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
FreeBSD bugmaster | 3 Mar 2008 12:07
Picon
Favicon

Current problem reports assigned to freebsd-arch <at> FreeBSD.org

Current FreeBSD problem reports
Critical problems
Serious problems
Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/120749  arch       [request] Suggest upping the default kern.ps_arg_cache

1 problem total.

_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
David O'Brien | 5 Mar 2008 00:30
Picon
Favicon

Tweaking the "Remaking Makefiles" feature

Last year Max Khon implemented something called the "Remaking Makefiles"
feature to make(1):
  After reading Makefile and all the files that are included using .include
  or .sinclude directives (source Makefiles) make considers each source
  Makefile as a target and tries to rebuild it.  Both explicit and implicit
  rules are checked and all source Makefiles are updated if necessary. If
  any of the source Makefiles were rebuilt, make restarts from clean state.
  ..
  When remaking a source Makefile options -t (touch target), -q (query
  mode), and -n (no exec) do not take effect, unless source Makefile is
  specified explicitly as a target in make command line.
  Additionally, system makefiles and .depend are not considered as a
  Makefiles that can be rebuilt.

While I find the feature neat, I find this feature (enabled by default)
way too dangerous.  It caused a major problem with the CVS 1.11.22 import
I did, and I feel it could easily catch others off guard.  So I think it
should be turned off by default.  (How many of you didn't realize 'make
-n' could write to files?)

I propose a new directive called ".MAKEFILEDEPS" which enables it.
(TODO: man page update)

Index: globals.h
===================================================================
RCS file: /home/ncvs/src/usr.bin/make/globals.h,v
retrieving revision 1.11
diff -u -p -r1.11 globals.h
--- globals.h	8 Mar 2007 09:16:10 -0000	1.11
+++ globals.h	4 Mar 2008 22:14:27 -0000
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Roberson | 7 Mar 2008 13:16

Getting rid of the static msleep priority boost

Hello,

I've been studying some problems with recent scheduler improvements that 
help a lot on some workloads and hurt on others.  I've tracked the problem 
down to static priority boosts handed out by msleep/cv_broadcastpri.  The 
basic problem is that a user thread will be woken with a kernel priority 
thus allowing it to preempt a thread running on any processor with a 
lesser priority.  The lesser priority thread may in fact hold some 
resource that the higher priority thread requires.  Thus we context switch 
several times and perhaps go through priority propagation as well.

I have verified that disabling these static priority boosts entirely fixes 
the performance problem I've run into on at least one workload.  There are 
probably others that it helps and hopefully we can discover that.

I'd like to know if anyone has a strong preference to keep this feature. 
It is likely that it helps in some interactive situations.  I'm not sure 
how much however.  I propose that we make a sysctl that disables it and 
turn it off by default.  If we see complaints on current <at>  we can suggest 
that they toggle the sysctl to see if it alleviates problems.

Based on feedback from that experiment and some testing we can then choose 
a few options:

1)  Disable the static boosts entirely.  Leave kernel priorities for 
kernel threads and priority propagation.  Most other kernels do this. 
Would make my life in ULE much easier as well.

2)  Leave the support for static boosts but remove it from all but a few 
key locations.  Leaving it in the api would give some flexibility but
(Continue reading)

Permalink | Reply | 18 comments |
headers
John Baldwin | 7 Mar 2008 14:42
Picon
Favicon

Re: Getting rid of the static msleep priority boost

On Friday 07 March 2008 07:16:30 am Jeff Roberson wrote:
> Hello,
>
> I've been studying some problems with recent scheduler improvements that
> help a lot on some workloads and hurt on others.  I've tracked the problem
> down to static priority boosts handed out by msleep/cv_broadcastpri.  The
> basic problem is that a user thread will be woken with a kernel priority
> thus allowing it to preempt a thread running on any processor with a
> lesser priority.  The lesser priority thread may in fact hold some
> resource that the higher priority thread requires.  Thus we context switch
> several times and perhaps go through priority propagation as well.
>
> I have verified that disabling these static priority boosts entirely fixes
> the performance problem I've run into on at least one workload.  There are
> probably others that it helps and hopefully we can discover that.
>
> I'd like to know if anyone has a strong preference to keep this feature.
> It is likely that it helps in some interactive situations.  I'm not sure
> how much however.  I propose that we make a sysctl that disables it and
> turn it off by default.  If we see complaints on current <at>  we can suggest
> that they toggle the sysctl to see if it alleviates problems.
>
> Based on feedback from that experiment and some testing we can then choose
> a few options:
>
> 1)  Disable the static boosts entirely.  Leave kernel priorities for
> kernel threads and priority propagation.  Most other kernels do this.
> Would make my life in ULE much easier as well.
>
> 2)  Leave the support for static boosts but remove it from all but a few
(Continue reading)

Permalink | Reply | 5 comments |
headers
John Baldwin | 7 Mar 2008 16:16
Picon
Favicon

Re: Getting rid of the static msleep priority boost

On Friday 07 March 2008 08:42:37 am John Baldwin wrote:
> On Friday 07 March 2008 07:16:30 am Jeff Roberson wrote:
> > Hello,
> >
> > I've been studying some problems with recent scheduler improvements that
> > help a lot on some workloads and hurt on others.  I've tracked the
> > problem down to static priority boosts handed out by
> > msleep/cv_broadcastpri.  The basic problem is that a user thread will be
> > woken with a kernel priority thus allowing it to preempt a thread running
> > on any processor with a lesser priority.  The lesser priority thread may
> > in fact hold some resource that the higher priority thread requires. 
> > Thus we context switch several times and perhaps go through priority
> > propagation as well.
> >
> > I have verified that disabling these static priority boosts entirely
> > fixes the performance problem I've run into on at least one workload. 
> > There are probably others that it helps and hopefully we can discover
> > that.
> >
> > I'd like to know if anyone has a strong preference to keep this feature.
> > It is likely that it helps in some interactive situations.  I'm not sure
> > how much however.  I propose that we make a sysctl that disables it and
> > turn it off by default.  If we see complaints on current <at>  we can suggest
> > that they toggle the sysctl to see if it alleviates problems.
> >
> > Based on feedback from that experiment and some testing we can then
> > choose a few options:
> >
> > 1)  Disable the static boosts entirely.  Leave kernel priorities for
> > kernel threads and priority propagation.  Most other kernels do this.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Robert Watson | 7 Mar 2008 17:01
Picon
Favicon

Re: 8.0 network stack MPsafety goals

On Mon, 24 Dec 2007, Robert Watson wrote:

> Date		Goals
> ----		-----
> 26 Dec 2007	Post proposed schedule for flag and infrastructure removal
> 		Post affected driver list
>
> 26 Jan 2008	Repost proposed schedule for flag and infrastructure removal
> 		Post updated affected driver list
>
> 26 Feb 2008	Adjust boot-time printf for affect drivers to generate a loud
> 		warning.
> 		Post updated affected driver list

Dear all,

Per the in-progress plan to remove IFF_NEEDSGIANT support, I have increased 
the verbosity of the boot-time warning for IFF_NEEDSGIANT-dependent network 
interface drivers.  8-CURRENT users who are seeing this more verbose warning 
in their dmesg might want to watch out for the next two scheduled steps in May 
and June respectively.  I've attached the remainder of the schedule and 
related details below.

Thanks,

Robert N M Watson
Computer Laboratory
University of Cambridge

> 26 May 2008	Post HEADS UP of impending driver disabling
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kirk McKusick | 7 Mar 2008 16:40

Re: Getting rid of the static msleep priority boost

> From: John Baldwin <jhb <at> freebsd.org>
> To: Jeff Roberson <jroberson <at> chesapeake.net>
> Date: Fri, 7 Mar 2008 08:42:37 -0500
> Cc: arch <at> freebsd.org
> Subject: Re: Getting rid of the static msleep priority boost
> 
> On Friday 07 March 2008 07:16:30 am Jeff Roberson wrote:
> > Hello,
> >
> > I've been studying some problems with recent scheduler improvements that
> > help a lot on some workloads and hurt on others.  I've tracked the problem
> > down to static priority boosts handed out by msleep/cv_broadcastpri.
> > ...
> 
> ...
>
> This change allows the decision on priority boost to be a scheduler
> decision to ignore it (so 4BSD could continue to do what it does now,
> but ULE may ignore it, or ignore certain levels, etc.)
> 
> -- 
> John Baldwin

I strongly agree with John's suggestion. The 4BSD scheduler will continue
to have its historic behavior (which was `tuned' by careful selection of
priority boosts) while more sophisticated schedulers like ULE will be able
to use/ignore the priority boosts based on their better knowledge of system
behavior.

	Kirk McKusick
(Continue reading)

Permalink | Reply | 1 comment |
headers
Daniel Eischen | 7 Mar 2008 17:19
Picon
Favicon

Re: Getting rid of the static msleep priority boost

On Fri, 7 Mar 2008, Jeff Roberson wrote:

> Hello,
>
> I've been studying some problems with recent scheduler improvements that help 
> a lot on some workloads and hurt on others.  I've tracked the problem down to 
> static priority boosts handed out by msleep/cv_broadcastpri.  The basic 
> problem is that a user thread will be woken with a kernel priority thus 
> allowing it to preempt a thread running on any processor with a lesser 
> priority.  The lesser priority thread may in fact hold some resource that the 
> higher priority thread requires.  Thus we context switch several times and 
> perhaps go through priority propagation as well.
>
> I have verified that disabling these static priority boosts entirely fixes 
> the performance problem I've run into on at least one workload.  There are 
> probably others that it helps and hopefully we can discover that.
>
> I'd like to know if anyone has a strong preference to keep this feature. It 
> is likely that it helps in some interactive situations.  I'm not sure how 
> much however.  I propose that we make a sysctl that disables it and turn it 
> off by default.  If we see complaints on current <at>  we can suggest that they 
> toggle the sysctl to see if it alleviates problems.
>
> Based on feedback from that experiment and some testing we can then choose a 
> few options:
>
> 1)  Disable the static boosts entirely.  Leave kernel priorities for kernel 
> threads and priority propagation.  Most other kernels do this. Would make my 
> life in ULE much easier as well.
>
(Continue reading)

Permalink | Reply | 11 comments |

Gmane