icult, which is why I am
suggesting that it simply be made into an exclusive lock in -current.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:--- Matthew Dillon <[EMA
I have no idea what the frig you guys are doing in vm_map.c. I would
recommend that all the changes be backed out. Then I would recommend
that the following be done:
* change the lockmgr vm_map lock to be exclusive-only
* test & commit
* change the lockmgr vm
:> mcopymap(from, to, length, flags)
:
:I'm not sure you want to copy it..
:I mean you want the dta di disappear from the old address.
:It's more a "movepages()"
MAP_MOVE|MAP_SHARED
-Matt
:>
:> flags:
:>
:> MAP_SHARED share the sa
write, as if you fork()d and the parent
was the original area and the child is the new
area.
But I'm not volunteering.
-Matt
Matt
e mmap
manual page describes this in detail.
MADV_FREE can be used in liu of munmap() but phkmalloc does not use
it quite this way, phkmalloc will still free the page when the cache
is blown out.
-Matt
by a factor of 15 to 25.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
#include
#include
#include
int
main(int ac, char **av)
{
char *ptr = NULL;
int i;
for (
or the fast-interrupt-restart
case either.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:On 08-Mar-02 Matthew Dillon wrote:
:>
:>:I agree that the use of cpu_critical_enter/exit could use cleaning up.
:>:Can you give an example of where critical_enter is used improperly?
:>:You mean in fork_exit? Your changes to cpu_switch solve that problem
:>:with critical_exit a
interrupt it should be able to handle a fast-unpend.
If it doesn't work then it's almost certainly a simple fix to adjust
the fake trap frame which can be done post-commit.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:Perhaps that part of the update could be considered "cosmetic", and
:thus be done as a separate update -- just so people can tell which
:lines are cosmetic changes and which ones are substantive. That is
:more work for you, but it makes it easier on reviewers, and it is
:certainly consistent wi
pper in the least.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
e. Big fucking deal!
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:I don't pretend to understand all the issues here, but I think it's
:important to recognize that there have been
REASON to keep a forced split and plenty of reasons to move it to MD.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
on.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:
:In otherwords. You acted unilaterally. You seem to be making my
:arguments for me. Again. Thanks!
No, I am not acting unilaterally, but neither do I feel it is appropriate
to be told to wait indefinitely (and I am STILL waiting by the way!).
When I commit something it isn't set
you believe it does. Not a
single person has been able to supply a single fact showing how it
interferes so significantly with any other work that it must not go
in at any cost, and that really pisses the hell out of me.
I will repeat: This is a damn good patch. I want to see
a bit better, uses the new flexibility to implement a better backend
for I386, and fixes a couple of nasty bugs to boot. It's important to
me but I don't see how it could possibly have any adverse effect on
the project and, frankly, I don't see why a
:My 2 cents? Work with John to get the APIs that affect this particular
:code stable. That means discussion and perhaps that discussion will
:take some time (if this blow-up hadn't occurred the discussion
:would already be over now ;-). Once the APIs are in place, commit your
:code in a format
;t ignore it or assume
that I am some beginner who's just throwing random commits in and
destabilizing the tree. I have gone to great lengths to do the precise
opposite of that.
-Matt
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
I think it may just be my-bad. The kernel source got out of sync
with the main tree. I just cvs updated the whole smelly pot and
buildworld works just fine.
Sorry for the false alarm!
-Matt
:
:At 1:15 PM -0800 3/6/02, Matthew
27;t consider it all that
significant and I will be happy to do it in the stage-2 commit.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
This has been broken for several days now, maybe longer. It would be
nice if whoever broke it would fix it.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
cc -no
:
:In message <[EMAIL PROTECTED]>, Matthew Dillon wri
:tes:
:
:>That's the crux of the situation, John. I do not believe you have
:>the right to hold this work off, at least not based on any of the
:>explanations you have given so far.
:
:Why don't you for
t not based on any of the
explanations you have given so far.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:--
:
:John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeB
s declared
on the stack (which to my horror I actually use sometimes) or dynamic
braced auto initializers (which I don't).
It would be best to cleanup instances of these when we come across them.
-Matt
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:On Fri, 1 Mar 2002, Glenn Gombert wrote:
:
:>I have spent several months figuring how to do diskless mounts for
:> test kernels, run debuggers from serial terminals and do remote kernel
:>
:>I strongly disagree. I have yet to see any technical description of
:>this so-called overall design that shows any incompatibility, and what
:>I decide to do with my time is my business.
:
:Matt,
:
:That particular protest is rather hollow, considering that you were
:one of the f
While I haven't specifically tested this patch it looks
reasonable to me. Are you going to do an engineering/commit
cycle with it?
-Matt
Matthew Dillon
&l
:
:
:On 28-Feb-02 Matthew Dillon wrote:
:> Not to put too fine a point on it, but, I don't see how this can
:> possibly justify preventing me from committing my critical_*() stuff.
:> You've just stated publically that your preemption stuff is unusable
:>
ent commit.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:>
:> Preemptive kernels don't even make it out of single user mode for SMP machines,
:> ok? We aren't talking minor breakage here
:On Wed, Feb 27, 2002 at 09:33:48AM -0800, Matthew Dillon wrote:
:> I'm just going to use this opportunity to plug the concept of tempora=
:ry
:> sysctl-instrumentation for a commit like this. =20
:
:Any thoughts on having a root oid for sysctl oids like this, so they'r
:
:ok so I leave it to other people to fix LINT
:I'm not going near it any more
It's the responsibility of whoever added -Werror to the default
compile to unbreak the tree, either by fixing the problem or by
backing out his commit.
-Matt
To U
the casts. It reminds us that there is something funny
going on.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:Matthew Dillon wrote:
:> :date: 2002/02/27 09:51:32; author: peter; state: Exp; lines: +245 -191
:> :Back out all the pmap related stuff I've touched over the last few days.
:> :There is some unresolved badness that has been eluding me, particularly
:> :affecting uni
:date: 2002/02/27 09:51:32; author: peter; state: Exp; lines: +245 -191
:Back out all the pmap related stuff I've touched over the last few days.
:There is some unresolved badness that has been eluding me, particularly
:affecting uniprocessor kernels. Turning off PG_G helped (which is a bad
:s
My general opinion is that a developer should not claim ownership of
anything, it should simply be apparent from the traffic the developer
posts to the public lists, discussion, and his commits. This implies
that the developer is only actively working on one thing at a time,
a
critical_*() available
to the MI code) when the existing critical_*() API will do the job
just fine.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail
mption
then the hacks you've thrown together!
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
followup cleanup commit, not quite, but maybe the one
after. It puts us on the right road.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL
revent me from contributing to the SMP work in -current
for a forth time because it doesn't exactly match your dream or
N-month-old stale patches you might have sitting around in P4.
-Matt
Matthew Dillon
:
:
:On 24-Feb-02 Matthew Dillon wrote:
:> Apart from all the assembly coding, there were two serious issues.
:> fork_exit() assumes that interrupts are hard-disabled on entry. I
:> readjusted the code such that the trampoline assembly initialized
:> the td_critnest
:> Just as a data point, I've been running -current on a 2xCPU SMP
:> system (DELL2550) for a few weeks and it's always booted fine.
:>
:> For the last few months I have noticed occassional freezes occuring
:> at odd times long after boot. I have no idea why it happens.
:
:Your
and forth.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
fork_exit() has no business making
those kinds of assumptions).
For the moment I'm not going to worry about it. I'll just keep the
cpu_critical_*() API intact for i386 for now.
-Matt
Matt
:
:On Mon, 25 Feb 2002, Matthew Dillon wrote:
:
:> Unless an unforseen problem arises, I am going to commit this tomorrow
:> and then start working on a cleanup patch. I have decided to
:
:Please wait for jhb's opinion on it. He seems to be offline again.
:I think he ha
Unless an unforseen problem arises, I am going to commit this tomorrow
and then start working on a cleanup patch. I have decided to
keep the sysctl instrumentation intact for the moment so people who
experience panics or lockups can turn it off to see whether that was the
cau
sed as
an interlock even more then it is being used to cover scheduler
queueing operations. I think the direction I would take would be
to try to address sched_lock's use rather then try to special case
interrupts.
-Matt
:...
:> stuff (it was not used on that machine) and it booted fine, I think that
:> might just cure the SMP problem you are seeing too.
:
:Thanks for the suggestion.
:
:Unfortunately it still hangs with SMP enabled and the ATA drivers commented
:out of the GENERIC config.
:
:Ken
:--
:Kenneth
:pid 214 guid/sec 687816Two TU's running, old critical_*()
:pid 214 guid/sec 6876321.454 uS/call
:pid 214 guid/sec 687857
:pid 214 guid/sec 687887
:pid 214 guid/sec 667454new critical_*()
:pid 214 guid/sec 6675621.496 uS/call
s that assumption at the moment but the
commit will only correct the assumption for I386. It will not change
anything for the other architectures (i.e. the assumption can still be
made for the other architectures).
-Matt
Ok, I've done a more comprehensive test. TU = getuid() syscall test.
This is on a 2xCPU SMP box.
With one process running the syscall is 34 nS faster with the
new critical_*(). With two processes running the syscall is
41 nS faster with the new critical_*().
So, not 3
:Removing cli and sti from the critical functions saves us 300 ns on
I'm going to make a correction here... I didn't realize I had WITNESS
turned on. 300ns of savings makes a lot of sense when WITNESS is turned
on because witness manipulates a number of spin locks.
I am goi
n). But for I386 I suppose I could just rename them
to intr_disable() and intr_restore(). I don't understand your
comment about functionality, they work just fine. It's just the name
that needs changing.
-Matt
pt to a cpu that is not
in a critical section ...
... else set bit in local ipending mask.
}
} else {
... take or schedule interrupt ...
}
}
-Matt
was cleaner to mask level interrupts and throw everything into
the same ipending hopper.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:
:On Sun, 24 Feb 2002, Matthew Dillon wrote:
:
:> * debug.critical_mode sysctl. This will not be in the final commit,
:> nor will any of the code that tests the variable. The final commit
:> will use code as if the critical_mode were '1'.
:
:Won't it
NOTES:
I would like to thank Bruce for supplying the sample code that allowed
me to do this in a day instead of several days.
* debug.critical_mode sysctl. This will not be in the final commit,
nor will any of the code that tests the variable. The final commit
will use
I'm going to wait until tomorrow before posting it. I have a bunch of
cleanup to do.
Bruce, your sys.dif was *invaluable*! It would have taken me a lot
longer to figure out the interrupt disablement requirement around
the icu_lock, and the statclock and hardclock forwarding
pt is pending' flag for critical_exit() to
test.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:
:On Sat, 23 Feb 2002, Matthew Dillon wrote:
:
:> :It's too messy and unfinished (doesn't work right for SMP or irqs >= 16),
:> :and dificult to untangle from my other patches. I posted these partial
:> :ones to attempt to inhibit() recomplication of the current crit
a little further along.
How should I deal with fast interrupts?
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:
:On Sat, 23 Feb 2002, Matthew Dillon wrote:
:
:> :My version of it does less than this. I only use it to help implement
:> :spinlocks.
:>
:> You put together infrastructure to deal with pending pci interrupts?
:> If so, then why not commit it (or at least commit a v
Bruce, I've looked at the vector assembly and it looks like cleaning
up critical_enter() and critical_exit() for i386 ought to be simple.
If you have a complete patch set I would like to see it posted for
review or comitted, or if you don't want to deal with the commit I
woul
:
:* Matthew Dillon <[EMAIL PROTECTED]> [020223 14:43] wrote:
:> This is approximately what I am thinking. Note that this gives us the
:> flexibility to create a larger infrastructure around the bucket cache,
:> such as implement per-cpu caches and so on and so fort
cture).
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:Index: kern_switch.c
:===
:RCS file: /home/ncvs/src/sys/kern/kern_switch.c,v
:retrievi
have to do is check the
critical nesting count from the interrupt code and set the
interrupts-disabled bit in the returned (supervisor mode) frame.
critical_enter() and critical_exit() would then be nearly perfect.
-Matt
This is approximately what I am thinking. Note that this gives us the
flexibility to create a larger infrastructure around the bucket cache,
such as implement per-cpu caches and so on and so forth. What I have
here is the minimal implementation.
ing it via malloc().
What do people think?
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:By the way, since "MAXALLOCSAVE" is some multiple of PAGE_SIZE, we
:really don't have to worry about it when
r the MALLOC.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
MP-related bug, good fucking luck find it!
How long do you want it to take to get a stable 5.x release? Because
the way you are going it isn't going to happen until we hit 5.3 or so.
-Matt
Matthe
:> I'm currently testing the following patch whcih is a subset of the td_ucred
:> changes. It involves no API changes, but only contains 2 basic changes:
:>
:> 1) We still need Giant when doing the crhold() to set td_ucred in
:>cred_update_thread(). This is an old bug that is my fault. I k
:The existing very bazaar and local policy in rc.diskless1 is Just Wrong;
:and looks like no other Unix diskless configuration I've ever seen. I
:plan on committing this patch to negate this.
:
:The use of an MFS /var should also be settable. Otherwise installing
:ports(packages) is just a tota
:Matthew Dillon wrote:
:> I'm not interested in using P4. I think it's a mistake. That is, I
:> think it is being severely overused. At the very least it is preventing
:> me from comitting simple things to -current because as far as I can tell
:> wh
:On Monday, 18 February 2002 at 15:38:07 -0500, Jake Burkholder wrote:
:> Apparently, On Mon, Feb 18, 2002 at 11:51:44AM -0800,
:> Matthew Dillon said words to the effect of;
:>> I'm fairly sure JHB does not have a patch to address this but, please,
:>> b
This sounds better but why do we need a 'pause' at all? I don't
think spinning in this case will have any effect on power
consumption.
-Matt
t bring up a potential
issue in the interrupt-thread-borrowing code. The ucred design is
very clean.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscrib
. you see where this is leading?
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:
:So, John's last few months of work is junk then, is it?
:
:Cheers,
:-Peter
:--
:Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
I'll tell you what is junk... patches for things like getuid() sitting
in P4 (whether instrumented or not). That's junk.
I'll tell
:> -mtx_lock(&Giant);
:> -td->td_retval[0] = p->p_ucred->cr_ruid;
:> +s = mtx_lock_giant(kern_giant_ucred);
:> +td->td_retval[0] = td->td_ucred->cr_ruid;
:> #if defined(COMPAT_43) || defined(COMPAT_SUNOS)
:> -td->td_retval[1] = p->p_ucred->cr_uid;
:> +td->td_retval[1] = td
It's as though procrunnable() is broken.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
2
#16 0xc019c0e4 in fork_exit (callout=0xc019cae0 ,
arg=0xc5b87400, frame=0xe04b8d48)
at /FreeBSD/FreeBSD-current/src/sys/kern/kern_fork.c:787
And I'm not sure why.
-Matt
Matthew Dillon
I should be checking for
critnest > 1.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-cur
I am doing).
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:
:I can't see any major problem with this but I can't help thinking that
:there must be one.. on UP the question is: "who is going to
:release the lock if no-one is runnable?"
An interrupt, of course. Wakeups don't happen out of thin air! This
is true of 1.x, 2.x, 3.x, 4.x, 5.x, UP, a
Here are my giant related patches to date. These are NOT all commit
candidates. Some are just hacks to test Giant removal. Julian is
responsible for the td_ucred persistance stuff. The hack in userret()
is just a hack to remove Giant when no signals are present in order to
: "Are you out of
your mind?".
I'm fairly sure JHB does not have a patch to address this but, please,
be my guest and check P4.
-Matt
Matthew Dillon
While testing some Giant removal stuff I noticed that my current
system sometimes got into an extremely non-optimal flip-flop situation
between two processes contesting Giant on an SMP system which halved the
syscall performance in the test.
In my getuid test, for example, wit
comitted
to the tree relatively soon.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:Sounds like we need to smack whoever made your chipset as well. Intel
:learned their lesson (finally) with later revisions of the PIIX4. I'm
:guessing you're running this against a ServerWorks system.
atapci0: port 0x8b0-0x8bf at device 15.1 on
pci0
Uh huh.
It might be possible
Ok, here is a patch that executes a brute-force solution to the
asynchronous counter problem.
Basically it figures out a mask and then the timer code loops until two
masked reads yield the same value, guarenteeing that we haven't caught
the timer during a carry.
On my sys
MISREAD 39f3161d 39f3161a 39f3161c
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
three.
I'll investigate further.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Whoop! I take it back. I'm still getting the errors:
microuptime() went backwards (458.168990 -> 458.168882)
microuptime() went backwards (578.609995 -> 577.929801)
microuptime() went backwards (748.912755 -> 748.237402)
microuptime() went backwards (775.159625 -> 775.159612)
I also th
:Bruce's patch amounts to a retry if the current timecounter was updated
:while we were calculating time. It is a bit more defensive than it
:needs to be and generally pessimizes the timecounters elegant lockless
:design a fair bit, but it is still much better than slamming a mutex
:around the en
Ok, I've looked at the code more carefully and I understand how this
works now. However, it is not enough in an SMP environment. You
need a generation count in the timecounter structure and you also need
a synchronization point when you switch time counters or a process
runni
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
:%%%
:Index: kern_tc.c
:===
:RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v
:retrieving revision 1.113
:diff -c
acpi_pcib0: on acpi0
...
Question: How can this be occuring at all? Isn't the ACPI counter a
32 bit counter that does not have the rollover problems that the 8254 timer
has?
-Matt
Matthew Dillon
Please review this patch. I haven't looked at BDE's patch but this was
so simple I decided to just go do it.
There are many situations where the allocation of a system structure can
be safely done with Giant, but deallocation occurs dangerously deep
in the call stack. For t
:Recent, USB change break world. The following patch
:fixes the broken world, but not be best patch.
:
:--
:Steve
:
:--- usbdevs.c.orig Sat Feb 16 12:19:10 2002
:+++ usbdevs.c Sat Feb 16 12:26:41 2002
:@@ -88,8 +88,17 @@
: done[a] = 1;
: printf("addr %d: ", di.addr);
:...
201 - 300 of 1252 matches
Mail list logo
