Titre du Cours
Encadrer et motiver une équipe
Comme manager et chef d'équipe, votre rôle consiste à assurer la contribution
des membres de votre
équipe, à la réalisation des objectifs et de la mission de l'organisation. Vous
On Wed, Dec 19, 2007 at 11:44:00AM -0800, Julian Elischer wrote:
> David G Lawrence wrote:
> >>> In any case, it appears that my patch is a no-op, at least for the
> >>>problem I was trying to solve. This has me confused, however, because at
> >>>one point the problem was mitigated with it. The pat
Anyone else noticed on 7.0BETA4 (& hence Ive cc'd re@)
This runs forever:
===> cc_int (all)
Warning: Object directory not changed from original
/usr/src/gnu/usr.bin/cc/cc_int
cc -O2 -fno-strict-aliasing -march=i586 -DIN_GCC -DHAVE_CONFIG_H
-DPREFIX=\"/usr\" -I/usr/src/gnu/usr.bin/cc/cc_int/../
David G Lawrence wrote:
In any case, it appears that my patch is a no-op, at least for the
problem I was trying to solve. This has me confused, however, because at
one point the problem was mitigated with it. The patch has gone through
several iterations, however, and it could be that it was mad
On Wed, 19 Dec 2007, David G Lawrence wrote:
The patch should work fine. IIRC, it yields voluntarily so that other
things can run. I committed a similar hack for uiomove(). It was
It patches the bottom of the loop, which is only reached if the vnode
is dirty. So it will only help if there
Just to confirm the patch did not change the behavior. I ran with it
last night and double checked this morning to make sure.
It looks like if you put the check at the top of the loop and the
next node
is changed during msleep() SLIST_NEXT will walk into the trash. I'm
in over my head here..
On Wed, Dec 19, 2007 at 08:11:59PM +0200, Kostik Belousov wrote:
> On Wed, Dec 19, 2007 at 09:13:31AM -0800, David G Lawrence wrote:
> > > >Try it with "find / -type f >/dev/null" to duplicate the problem
> > > >almost
> > > >instantly.
> > >
> > > I was able to verify last night that (cd /; tar
On Wed, Dec 19, 2007 at 09:13:31AM -0800, David G Lawrence wrote:
> > >Try it with "find / -type f >/dev/null" to duplicate the problem
> > >almost
> > >instantly.
> >
> > I was able to verify last night that (cd /; tar -cpf -) > all.tar would
> > trigger the problem. I'm working getting a test
On Thu, 20 Dec 2007, Bruce Evans wrote:
On Wed, 19 Dec 2007, David G Lawrence wrote:
Considering that the CPU clock cycle time is on the order of 300ps, I
would say 125ns to do a few checks is pathetic.
As I said, 125 nsec is a short time in this context. It is approximately
the time for a
On Wed, 19 Dec 2007, David G Lawrence wrote:
Try it with "find / -type f >/dev/null" to duplicate the problem almost
instantly.
FreeBSD used to have some code that would cause vnodes with no cached
pages to be recycled quickly (which would have made a simple find
ineffective without reading
> >Try it with "find / -type f >/dev/null" to duplicate the problem
> >almost
> >instantly.
>
> I was able to verify last night that (cd /; tar -cpf -) > all.tar would
> trigger the problem. I'm working getting a test running with
> David's ffs_sync() workaround now, adding a few counters there
> > In any case, it appears that my patch is a no-op, at least for the
> >problem I was trying to solve. This has me confused, however, because at
> >one point the problem was mitigated with it. The patch has gone through
> >several iterations, however, and it could be that it was made to the top
On Dec 19, 2007, at 9:54 AM, Bruce Evans wrote:
On Tue, 18 Dec 2007, Mark Fullmer wrote:
A little progress.
I have a machine with a KTR enabled kernel running.
Another machine is running David's ffs_vfsops.c's patch.
I left two other machines (GENERIC kernels) running the packet
loss tes
On Wed, 19 Dec 2007, David G Lawrence wrote:
Debugging shows that the problem is like I said. The loop really does
take 125 ns per iteration. This time is actually not very much. The
Considering that the CPU clock cycle time is on the order of 300ps, I
would say 125ns to do a few checks i
David G Lawrence wrote:
Try it with "find / -type f >/dev/null" to duplicate the problem almost
instantly.
FreeBSD used to have some code that would cause vnodes with no cached
pages to be recycled quickly (which would have made a simple find
ineffective without reading the files at lea
>In any case, it appears that my patch is a no-op, at least for the
> problem I was trying to solve. This has me confused, however, because at
> one point the problem was mitigated with it. The patch has gone through
> several iterations, however, and it could be that it was made to the top
> o
> Try it with "find / -type f >/dev/null" to duplicate the problem almost
> instantly.
FreeBSD used to have some code that would cause vnodes with no cached
pages to be recycled quickly (which would have made a simple find
ineffective without reading the files at least a little bit). I guess
th
> On Tue, 18 Dec 2007, David G Lawrence wrote:
>
> >>>I got an almost identical delay (with 64000 vnodes).
> >>>
> >>>Now, 17ms isn't much.
> >>
> >> Says you. On modern systems, trying to run a pseudo real-time
> >> application
> >>on an otherwise quiescent system, 17ms is just short of an e
On Tue, 18 Dec 2007, Mark Fullmer wrote:
A little progress.
I have a machine with a KTR enabled kernel running.
Another machine is running David's ffs_vfsops.c's patch.
I left two other machines (GENERIC kernels) running the packet loss test
overnight. At ~ 32480 seconds of uptime the proble
On Tue, 18 Dec 2007, David G Lawrence wrote:
I got an almost identical delay (with 64000 vnodes).
Now, 17ms isn't much.
Says you. On modern systems, trying to run a pseudo real-time application
on an otherwise quiescent system, 17ms is just short of an eternity. I agree
that the syncer sho
20 matches
Mail list logo
