Has anybody used AIO in conjunction with kevent?
I am seeing as much as a 12 second latency between
when I do an 8k aio_write to a file on local disk
and kevent returning its completion (I'm calling
kevent every ~20ms). Using regular writes works fine,
but this is a multi-threaded application so
It turns that this problem is specific to AIO in
-CURRENT. I wrote a simple program that uses
the three different completion mechanisms (polling
with aio_error, polling with kevent, and using SIGIO)
to fill up a file by writing 8kb at a time to the
file and then reading 8kb at a time from the fil
'
../../../libkern/mcount.c:91: warning: called from
here
machine/atomic.h:234: warning: inlining failed in call
to `atomic_store_rel_int'
../../../libkern/mcount.c:242: warning: called from
here
--- "Alan L. Cox" <[EMAIL PROTECTED]> wrote:
> k Macy wrote:
> >
>
Should I file a PR to track this or is that overkill?
-Kip
--- Bruce Evans <[EMAIL PROTECTED]> wrote:
> On Sat, 19 Jan 2002, k Macy wrote:
>
> > Thanks for working on this. I was going to try
> running
> > a profiled kernel on -CURRENT and -STABLE to se
Who is the current GDB maintainer?
-Kip
__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the bo
I asked BDE about the same thing off-list:
Yes, the debug options (INVARIANTS and WITNESS,
especially the latter)
slow down the kernel by a factor of 10 or so. Only
progams that don't
make many syscalls run reasonably fast. I only turn
on these options
for debugging (not often). Without them, s
>>
>> I have the same panic. I'll try to revert 205266.
>
> Yes, 205266 is the culprit.
Try updating. I've made the change a no-op until I can track the problem down.
-Kip
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis
On Thu, Mar 18, 2010 at 1:38 PM, K. Macy wrote:
>>>
>>> I have the same panic. I'll try to revert 205266.
>>
>> Yes, 205266 is the culprit.
>
> Try updating. I've made the change a no-op until I can track the problem down.
Do you all have either out-
On Fri, Mar 19, 2010 at 7:09 AM, David Wolfskill wrote:
> On Fri, Mar 19, 2010 at 01:09:11PM +, Rui Paulo wrote:
>> ...
>> > Do you all have either out-of-tree modules or modules that you did not
>> > re-build when re-compiling your kernel?
>>
>> I have in-tree modules, but I tried a clean bui
The current llvm-devel package is woefully out of date. Anyone wishing
to try this will need to compile the latest port.
-Kip
On Fri, Apr 16, 2010 at 9:08 AM, Roman Divacky wrote:
> Hi,
>
> ClangBSD is a branch of FreeBSD that aims at integrating clang
> (clang.llvm.org)
> into FreeBSD, replac
> Sadly, it doesn't do it for me .. lockd start-up causes a panic on a
> "sleeping thread". Do I need to do a buildworld as well as kernel?
>
We're calling vm_pageout_flush with the page queue lock held in
vm_object_page_collect_flush. I'll have a fix in soon.
Thanks,
Kip
___
On Fri, Apr 30, 2010 at 12:38 PM, K. Macy wrote:
>> Sadly, it doesn't do it for me .. lockd start-up causes a panic on a
>> "sleeping thread". Do I need to do a buildworld as well as kernel?
>>
>
> We're calling vm_pageout_flush with the page queue
How much memory do you have? I haven't been checking code in without
testing it, but clearly my system behaves a bit differently.
Please try 207452.
Thanks,
Kip
On Fri, Apr 30, 2010 at 2:42 PM, Manfred Antar wrote:
> At 02:21 PM 4/30/2010, K. Macy wrote:
>>On Fri, Apr 30, 2010
Hi Andrew,
Does FBSDID get expanded when checking out with csup?
You should see:
__FBSDID("$FreeBSD: head/sys/vm/vm_pageout.c 207452 2010-04-30
22:31:37Z kmacy $");
line 451 is part of a KASSERT on this version.
Cheers,
Kip
On Fri, Apr 30, 2010 at 4:12 PM, Andrew Reilly wrote:
> Hi all,
>
>
On Sat, May 8, 2010 at 2:20 PM, b. f. wrote:
> On 05/08/10 13:36, Alan Cox wrote:
>> Doug Barton wrote:
>>> On 05/05/10 11:56, Alan Cox wrote:
>>>
I'm afraid that I would advise waiting a few days. This round of
changes
are not yet complete.
>
> What performance differences, if any
Could you please try with 207902?
Thanks,
Kip
On Mon, May 10, 2010 at 11:26 AM, David Wolfskill wrote:
> On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote:
>> ...
>> You don't happen to have a backtrace?
>
> Oops -- sorry; got caught up in getting ready to head in to work:
>
> db> bt
>
On Mon, May 10, 2010 at 2:32 PM, K. Macy wrote:
> Could you please try with 207902?
And if not, please get a coredump with a backtrace with symbols.
Thanks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/free
Are you not able to dump core?
Thanks,
Kip
On Mon, May 10, 2010 at 3:08 PM, David Wolfskill wrote:
> On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote:
>> Could you please try with 207902?
>> ...
>
> First, thanks for the response.
>
> OK; I grabbed r207902 &
Please try 207949
Thanks,
Kip
On Tue, May 11, 2010 at 6:18 AM, David Wolfskill wrote:
> On Mon, May 10, 2010 at 02:32:14PM -0700, K. Macy wrote:
>> Could you please try with 207902?
>> ...
>
> I saved that environment (documented elsewhere ini the thread), then
&
On Tue, May 11, 2010 at 9:24 PM, David Wolfskill wrote:
> On Tue, May 11, 2010 at 08:30:09PM -0700, K. Macy wrote:
>> Please try 207949
>> ...
>
> The panic (this time) didn't show up until about 10 seconds after the
> login: prompt showed up on the serial c
Hi Hans,
It mostly looks fine, but it's a large change and there are some
places in the patch where it isn't clear that the right thing is being
done by looking at the patch alone. Please give us some time to
review.
Thanks.
-K
On Wed, Nov 19, 2014 at 11:02 AM, Hans Petter Selasky wrote:
> Hi
On Wed, Nov 19, 2014 at 1:34 PM, Hans Petter Selasky wrote:
> On 11/19/14 21:46, K. Macy wrote:
>>
>> Hi Hans,
>>
>> It mostly looks fine, but it's a large change and there are some
>> places in the patch where it isn't clear that the right thing is
>
> I wonder if that implies that any non-normal exit from a program that
> has been xo'd will result in the loss of output that would not have been
> lost before the xo changes? That could lead to all kinds of subtle
> failures of existing scripts and apps.
Well, so long as the app doesn't crash
On Mon, Mar 2, 2015 at 12:42 PM, Adrian Chadd wrote:
> Hi,
>
> gonzo@ committed a fix (r278615) to the videocore driver for the
> raspberry pi. The fix involved doing an explicit wire of pages that
> were about to be passed down to the hardware to send to the
> videobuffer hardware.
>
> It turns o
>> Right above vm_page_hold():
>> /*
>> * Keep page from being freed by the page daemon
>> * much of the same effect as wiring, except much lower
>> * overhead and should be used only for *very* temporary
>> * holding ("wiring").
>> */
>
> What's the definition of "very temporary holding" ? Wh
The value of the mutex in the stack trace indicates that it's a use after
free. There are various memory debugging options (memguard, redzone) that
may help track it down.
-K
On Jul 5, 2015 2:37 PM, "Larry Rosenman" wrote:
> I've gotten a couple of these:
>
> borg.lerctr.org dumped core - see /v
subr_syscall.c:133
>
> the td value.
>
> What would you suggest? This has become intermittent :(
>
>
> On 2015-07-06 00:42, K. Macy wrote:
>
>> The value of the mutex in the stack trace indicates that it's a use after
>> free. There are various memo
Is this still happening?
On Jul 15, 2015 1:41 PM, "Pawel Pekala" wrote:
> Hi John-Mark,
>
> On 2015-07-15 11:05 -0700, John-Mark Gurney wrote:
> >Please repost the entire panic message, and the back trace w/o X
> >running... Also, if you could share the core and kernel w/ me (you can
> >email m
Does this pre or postage input changes?
On Friday, March 25, 2016, O. Hartmann wrote:
> Since a couple of days now, FreeBSD CURRENT (at the moment with FreeBSD
> 11.0-CURRENT #9
> r297267: Fri Mar 25 09:48:07 CET 2016 amd64) "feels" a kind of shaky and
> like "glue": it
> is slow with X11, somet
Sorry meant inpcb and autocorrect "fixed" it.
On Saturday, March 26, 2016, O. Hartmann
wrote:
> Am Fri, 25 Mar 2016 13:31:31 -0700
> "K. Macy" > schrieb:
>
> > Does this pre or postage input changes?
>
> ???
>
> First of all, and the most vi
On Tuesday, April 19, 2016, Poul-Henning Kamp wrote:
> As far as I know, nobody is taking the source code or the Makefiles
> away, so if somebody doesn't like the system being distributed with
> pkg, they can very well roll their own.
>
> It's nice to see the level of enthusiasm the FreeBSD proje
On Tuesday, April 19, 2016, Adrian Chadd wrote:
> It's cool. I have positive and negative reactions, and I'm totally
> happy to let people try it out at a larger scale and learn from
> mistakes.
>
> Because, honestly - fuck it, we've been behind for too long. We need
> more mature tools and knowl
On Mon, Apr 18, 2016 at 12:14 PM, Glen Barber wrote:
> On Mon, Apr 18, 2016 at 12:01:46PM -0700, Sean Fagan wrote:
>> On Apr 18, 2016, at 11:52 AM, Lev Serebryakov wrote:
>> >
>> > I understand, that maybe it is too late, but ARE YOU KIDDING?! 755
>> > packages?! WHY?! What are reasons and goals
On Sat, Apr 30, 2016 at 4:45 PM, Pete Wright wrote:
> I recently acquired a Lenovo M900 Tiny desktop system which comes with an
> intel i7-6700T Skylate CPU and Intel HD 530 graphics processor. I am
> successfully running 11-CURRENT via EFI but have three devices which I am
> unable to fully util
I think hps@ has a fix for this that uses a sequency of DELAY()s. The
problem is that in freebsd, attach runs before the scheduler is
running. Consequently, code using sleep primitives tends to hang
because ticks never advance. The scheduler / threading starts much
earlier on linux.
-M
On Tue, Ma
I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
did an IFC to r300176 and boot will hang right ater printing out
"setting hostid: ". ^T just shows sh [piperd]. ddb just shows the
shell as hanging in piperead. Diffing between those two revisions I
don't see any obvious offenders
On Fri, May 20, 2016 at 11:33 AM, Johan Hendriks wrote:
> H
>
> Op vrijdag 20 mei 2016 heeft Joel Dahl het volgende
> geschreven:
>
>> On Fri, May 20, 2016 at 01:59:46PM +0200, O. Hartmann wrote:
>> > On Fri, 20 May 2016 13:55:50 +0200
>> > Joel Dahl > wrote:
>> >
>> > > Hi,
>> > >
>> > > I've ju
I'm seeing watchdog resets on em(4) in my VMWare as of the last day or two.
>
>
> I don't use ipfw, aliases or anything other than stock networking. I
> was unable to copy a large image off the VM without getting an
> unending stream of watchdog resets which could only be fixed by a
> reboot. Fort
Much to my chagrin, this too is my fault. Please apply the attached
patch if it hasn't yet been committed to -CURRENT.
On Fri, May 20, 2016 at 11:28 PM, Joel Dahl wrote:
> On Fri, May 20, 2016 at 07:32:30PM -0700, K. Macy wrote:
>> I'm seeing watchdog resets on em(4) in my VM
On Sunday, May 22, 2016, Tim Kientzle wrote:
> Crochet has some experimental hooks to install packages onto the system
> being built, but this seems to be hitting problems due to limitations in
> 'pkg -c'. In particular, it seems that pkg performs the chroot before it
> does any network lookups.
It will be fixed in the next iflib update.
On Thursday, May 26, 2016, Juan Ramón Molina Menor wrote:
> Hi!
>
> In three different machines running HEAD I have this message in the very
> first lines of the dmesg output:
>
> can't reuse a leaf (ixl_rx_miss_bufs)!
>
> I don’t remember seeing it bef
It looks like it might be trying to remove mappings for a page that doesn't
have any. It's a bit odd. Likely a bug in cdev_pager_free_page or gem
release mmap. Compile the kernel and driver with -O0 and look at the page.
It's too bad I don't support AGP yet with DRM 4.6. Maybe in a week or two.
-M
Just to clarify I'm talking about BSD install images, not my i915 tester.
On Friday, June 3, 2016, Matthew Macy wrote:
>
> In order to boot USB reliably on recent laptop hardware (both my thinkpad
> and XPS13 need this) you need to add the following to the installer images
> loader.conf:
>
> ker
On Tue, Jun 28, 2016 at 10:51 AM, Matthew Macy wrote:
> You guys should really look at Samy Bahra's epoch based reclamation. I solved
> a similar problem in drm/linuxkpi using it.
The point being that this is a bug in the TCP life cycle handling
_not_ in callouts. Churning the callout interface
On Wednesday, July 6, 2016, Don Lewis wrote:
> On 6 Jul, Matthew Macy wrote:
> > As a first step towards managing linux user space in a chrooted
> > /compat/linux, initially for i915 testing with intel gpu tools, later
> > on to get widevine and steam to work I'm trying to get apt to work.
> > I
Have you checked for BIOS updates? The BIOS on recent Skylake laptops
have been a running disaster. At least the Dell XPS laptops had ACPI
errors be fixed by an update.
-M
On Sat, Jul 30, 2016 at 10:43 PM, Ben Woods wrote:
> Hi everyone,
>
> I get the following ACPI errors in my dmesg when booti
On Sun, Jul 31, 2016 at 7:03 AM, Adrian Chadd wrote:
> Hi,
>
> Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are
> any performance degredations on lower count CPUs?
The adaptive spinning path will never run on a uniprocessor. Except
for potential i-cache displacement you're n
I get this panic periodically at iwm load time:
(kgdb) p ic->ic_tq
value has been optimized out
(kgdb) down
#12 taskqueue_drain (queue=0x0, task=0xfe004fc17150) at
/usr/home/mmacy/drm-next-4.6/sys/kern/subr_taskqueue.c:554
554 TQ_LOCK(queue);
(kgdb) bt
#0 __curthread () at ./machi
16 09:56, K. Macy wrote:
>>
>> #12 taskqueue_drain (queue=0x0, task=0xfe004fc17150) at
>
>
> Hi,
>
> Looks like a NULL pointer, queue=NULL
>
> --HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebs
On Thursday, August 4, 2016, Christian Schwarz wrote:
> Any idea which revision/commit introduced this regression?
>
> (I want to test iwm + freebsd-base-graphics on my laptop tonight and
> hence avoid crashers like this one in advance.)
>
> @mmacy: is the revision in the current drm-next-4.6 br
I have a KBL-Y "Software Development Platform" for purposes of getting
the i915 KMS working on that system on FreeBSD. I've just installed 11
BETA4. sdhci timeouts add several minutes to boot time. The dmesg
output follows:
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983
On Saturday, August 13, 2016, Adrian Chadd wrote:
> w!
>
> ok, what has to be committed to -head?
O.o
For the range of hardware supported by 3.8 just evdev and his drm kevent
patch. For anything newer (e.g. Cherryview) everything in my patch queue
that we've been talking about for at lea
On Monday, August 29, 2016, Volodymyr Kostyrko wrote:
> Matthew Macy wrote:
>
>> It looks like there is something broken with the devel/llvm38 port or
>> external toolchain support has regressed:
>>
>>
>> This works:
>> make XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37
>> XCPP=/usr/l
On Saturday, November 12, 2016, Mark Heily wrote:
> On Fri, Nov 11, 2016 at 11:41 PM, Kevin Oberman > wrote:
>
> >
> > In regard to video, have you installed and are you using vaapi?
> >
>
> vaapi appears to be preinstalled, however when I run "vainfo" it is unable
> to find a driver.
>
> The un
On Monday, November 14, 2016, Lars Engels wrote:
> On Sun, Nov 13, 2016 at 01:56:45PM -0800, K. Macy wrote:
> > On Saturday, November 12, 2016, Mark Heily > wrote:
> >
> > > On Fri, Nov 11, 2016 at 11:41 PM, Kevin Oberman
> > > > wrote:
> > &
>
>
>
A MachO activator is indeed not useful without an OSX install.
But let's be honest, Mach IPC is a loadable kernel module requiring no real
kernel changes. It's not upstreamable because of a general poor
understanding of IPC by noisy commentators and a religious aversion to a
technology perce
On Thu, Sep 15, 2011 at 9:22 PM, Andriy Gapon wrote:
> on 15/09/2011 19:20 Arnaud Lacombe said the following:
>> est0: failed to enable SpeedStep
>> p4tcc0: on cpu0
>> est1: failed to enable SpeedStep
>> p4tcc1: on cpu1
>> est2: failed to enable SpeedStep
>> p4tcc2: on cpu2
>> est3: failed to e
I was just discussing this issues with some others - evidently est(9)
works fine on both older and newer cpus. I see you're active on lkml -
does the linux driver work correctly on this machine? i.e. do you know
that it isn't disabled in the BIOS.
Thanks
On Thu, Sep 15, 2011 at 6:20 PM, Arnaud La
This is a side effect of the syscall namespace disambiguation. I will
send patches to the ports maintainers.
Thanks
On Sat, Sep 17, 2011 at 10:29 AM, Rainer Hurling wrote:
> Upgrading 9.0-BETA2 last night after r22561[78] was committed brings me
> trouble with at least to kmods from ports. They
You need to change the permissions. I'm getting a 403 from nginx.
On Sat, Oct 1, 2011 at 12:20 PM, Volodymyr Kostyrko wrote:
> Hi all.
>
> BETA3 dumps core on running heavy disk bound application. Built with clang
> and kernel is custom, but I can try to reproduce it on GENERIC if that
> matters.
Someone was seeing the same issue with the vmtools kmod. The only
thing that might make sense is that the page lock array is defined as
being a different size in your kmod as in the kernel itself so the
lock corresponding to the page you're locking differs between the two
files.
Cheers
On Fri, Oc
On Sat, Feb 25, 2012 at 2:15 PM, Attilio Rao wrote:
> Il 25 febbraio 2012 07:15, Doug Barton ha scritto:
>> On 02/24/2012 21:00, Doug Barton wrote:
>>> I'm on today's -current (r232126) and I'm getting the error in the
>>> subject when trying to start postfix. I recompiled 2.9, and then tried
>>>
.
>
> I tried it, on both FreeBSD routers, web systems, and database
> servers; all on 8.2+. It still causes massive instability. Disabling
> the sysctl, and/or removing it from the kernel solved the problems.
Routing I can believe, but I'm wondering how close attention you paid
to the workload. T
Inviato da iPad
Il giorno 01/mar/2012, alle ore 03:01, Steve Wills ha
scritto:
>
> The failure I experienced was with web servers running 8.0 behind a F5
> load balancer in an HA setup. Whenever the failover happened, the web
> servers would continue sending to the wrong MAC address, despite
> Yes, that was part of it. On the web and db systems we had what I can
> only describe as "general wackiness" with systems suddenly becoming
> unreachable, etc. This was with a moderately complex network setup with
> a combination of different VLANs, multiple interfaces, etc. The FreeBSD
> routers
> Apparently you've missed all the times that I've given that exact advice. :)
>
> But your analogy is severely flawed. Flowtable was an experimental
> feature that theoretically might have increased performance for some
> work flows, but turned out to be fatally flawed. The ports system is an
> es
>
> ... and here is the crux of the problem. The vast majority of our
> developers don't use FreeBSD as their regular workstation. So it has
> increasingly become an OS where changes are being lobbed over the wall
> by developers who don't run systems that those changes affect. That's no
> way to r
> No, I already pointed out the distinction between "new, experimental
> features;" and "essential components of the FreeBSD operating system."
> It's Ok for you to disagree with that distinction, or with its
> importance. But what you're suggesting is that if users don't help
> developers debug "c
> Less effort is required to get greater profit without having to mess
> around with things because they fit the generic case as opposed to a
> number of niche cases or provide OS features that a user may or may
> not use.
My initial venting of my frustrations at Doug appears to have turned
an ope
I'm re-sending this portion of another mail as it will inevitably not
be read by most readers by virtue of having been part of a long and
digressive thread.
subject line: "flowtable usable or not"
It is possible to re-structure the routing code to have a smaller
cache footprint / shorter lookup t
On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton wrote:
> On 03/03/2012 08:53, K. Macy wrote:
>> a) We as a members of the community are collectively responsible for
>> the state of FreeBSD. Simply disabling features or removing
>> functionality that doesn't work or doesn
On Sat, Mar 3, 2012 at 10:09 PM, Doug Barton wrote:
> On 03/03/2012 13:03, K. Macy wrote:
>> On Sat, Mar 3, 2012 at 9:54 PM, Doug Barton wrote:
>>> On 03/03/2012 08:53, K. Macy wrote:
>>>> a) We as a members of the community are collectively responsible for
>
>> This is indeed a big problem. I'm working (rough edges remain) on
>> changing the routing table locking to an rmlock (read-mostly) which
>
This only helps if your flows aren't hitting the same rtentry.
Otherwise you still convoy on the lock for the rtentry itself to
increment and decrement the
On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo wrote:
> On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
>> >> This is indeed a big problem. ?I'm working (rough edges remain) on
>> >> changing the routing table locking to an rmlock (read-mostly) which
&g
>> This only helps if your flows aren't hitting the same rtentry.
>> Otherwise you still convoy on the lock for the rtentry itself to
>> increment and decrement the rtentry's reference count.
>
>
> The rtentry lock isn't obtained anymore. While the rmlock read
> lock is held on the rtable the rele
>
> Yes, but the lookup requires a lock? Or is every entry replicated
> to every CPU? So a number of concurrent CPU's sending to the same
> UDP destination would content on that lock?
No. In the default case it's per CPU, thus no serialization is
required. But yes, if your transmitting thread ma
On Thu, Apr 19, 2012 at 11:27 PM, Andre Oppermann wrote:
> On 19.04.2012 23:17, K. Macy wrote:
>>>>
>>>> This only helps if your flows aren't hitting the same rtentry.
>>>> Otherwise you still convoy on the lock for the rtentry itself to
>>>&g
Comments inline below:
On Fri, Apr 20, 2012 at 4:44 PM, Luigi Rizzo wrote:
> On Thu, Apr 19, 2012 at 11:06:38PM +0200, K. Macy wrote:
>> On Thu, Apr 19, 2012 at 11:22 PM, Luigi Rizzo wrote:
>> > On Thu, Apr 19, 2012 at 10:34:45PM +0200, K. Macy wrote:
>> >> >>
Most of these issues are well known. Addressing the bottlenecks is
simply time consuming due to the fact that any bugs introduced during
development potentially impact many users.
-Kip
On Sun, Apr 22, 2012 at 4:14 AM, Adrian Chadd wrote:
> Hi,
>
> This honestly sounds like it's begging for an
> i
On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing wrote:
>>
> >From previous tests, the difference between flowtable and
>>routing table was small with a single process (about 5% or 50ns
>>in the total packet processing time, if i remember well),
>>but there was a large gain with multiple concurrent proce
On Tue, Apr 24, 2012 at 5:03 PM, K. Macy wrote:
> On Tue, Apr 24, 2012 at 4:16 PM, Li, Qing wrote:
>>>
>> >From previous tests, the difference between flowtable and
>>>routing table was small with a single process (about 5% or 50ns
>>>in the total pac
On Tue, Apr 24, 2012 at 6:34 PM, Luigi Rizzo wrote:
> On Tue, Apr 24, 2012 at 02:16:18PM +, Li, Qing wrote:
>> >
>> >From previous tests, the difference between flowtable and
>> >routing table was small with a single process (about 5% or 50ns
>> >in the total packet processing time, if i remem
Known problem. There is an open disagreement about how to improve the
granularity of locking in pmap.
-Kip
On Tue, Apr 24, 2012 at 9:14 PM, Slawa Olhovchenkov wrote:
> I treid make -j 30 build{world,kernel} (latest -CURRENT) on 24-core machine
> and see poor
> scalability of pmap/mtx -- more th
Slawa Olhovchenkov wrote:
> On Tue, Apr 24, 2012 at 09:27:30PM +0200, K. Macy wrote:
>
>> Known problem. There is an open disagreement about how to improve the
>> granularity of locking in pmap.
>
> split locking to process-specific information and global information?
It's a bit dated at this point. Nonetheless, when gitorious is able to
give something other than 503 to my search queries I'll post it.
On Tue, Apr 24, 2012 at 10:45 PM, Slawa Olhovchenkov wrote:
> On Tue, Apr 24, 2012 at 10:43:08PM +0200, K. Macy wrote:
>
>> No. I develo
You can try these. Your mileage *will* vary.
https://gitorious.org/~kmm/freebsd/kmm-sandbox/commits/work/svn_release_8_1_0_page_lock
https://gitorious.org/~kmm/freebsd/kmm-sandbox/commits/work/svn_trunk_page_lock
On Tue, Apr 24, 2012 at 10:51 PM, K. Macy wrote:
> It's a bit dated
some interest. This
the relevant part of the last mail that I received from you. The final
part having been dedicated to the narrow potential ABI changes that
were to make it in to the release.
From: Bjoern A. Zeeb
Date: Mon, Sep 19, 2011 at 3:19 PM
To: "K. Macy"
Cc: Robert Watson
It's highly chipset and processor dependent what works best. Intel now
has non-temporal loads and stores which work much better in some cases
but provide little benefit in others.
-Kip
On Wed, May 2, 2012 at 11:52 PM, Steven Atreju wrote:
> Luigi Rizzo wrote:
>> 2. apparently, bcopy is not the f
On Wed, Aug 20, 2014 at 7:41 AM, Luigi Rizzo wrote:
> On Wed, Aug 20, 2014 at 3:29 PM, Hans Petter Selasky
> wrote:
>
> > Hi Luigi,
> >
> >
> > On 08/20/14 11:32, Luigi Rizzo wrote:
> >
> >> On Wed, Aug 20, 2014 at 9:34 AM, Hans Petter Selasky
> >> wrote:
> >>
> >> Hi,
> >>>
> >>> A month has
>
>
>
>> - uint32_t -> m_flowid_t is plain gratuitous. Now we need to include
>>mbuf.h in more places just to get this definition. What's the
>>advantage of this? style(9) isn't too fond of typedefs either. Also,
>>drivers *do* need to know the width of the flowid. At least lagg(4)
This recent commit changed the way that the value for size being
passed to m_getjcl is initialized. Not seeing any obvious bugs, and
not having any additional context I would guess that that you're
receiving an interrupt before adapter->rx_mbuf_sz is set. I trust jfv@
to look in to this shortly.
h
On Tue, Jun 14, 2011 at 6:08 PM, K. Macy wrote:
> http://svnweb.freebsd.org/base/head/sys/sys/imgact.h
>
> kib added rudimentary support for this in January
To clarify, this is just the kernel side of the shared page
infrastructure, and is currently only hosting the the signal handling
http://svnweb.freebsd.org/base/head/sys/sys/imgact.h
kib added rudimentary support for this in January
On Tue, Jun 14, 2011 at 6:11 PM, Luigi Rizzo wrote:
> there were discussions at some point on an imprecise but
> fast implementations of gettimeofday() that would not require
> a system call (p
On Mon, Aug 29, 2011 at 2:12 PM, Adrian Chadd wrote:
> Hi,
>
> http://forums.nvidia.com/index.php?showtopic=38242 Post 18
>
> This indicates the driver supports CUDA somehow. What's missing is a
> FreeBSD runtime.
>
> Can someone please do some legwork with this and see if it's possible
> to bring
On Tue, Aug 30, 2011 at 9:47 PM, Pedro F. Giffuni wrote:
> FWIW;
>
> Christopher Bergström and Pathscale delivered the EKOPath
> Compiler Suite, but no one followed up:
>
> (From the WantedPorts Wiki)
> https://github.com/pathscale/path64-suite
>
> There has been very low interest in the FreeBSD p
> But the lack of response and non-shown interests shows a undeobtly signal
> that freeBSD seems to be
> dead for the HPC community and this could be also an indication for the lack
> of CUDA support
> by nVidia, Why performing efforts if no one cares? A great chance seems to
> have passed by ...
When WITNESS support was added to lockmgr locks a number of
longstanding LORs were exposed in the process. I can't comment on
whether or not they'll be fixed or the warnings will some day be
silenced.
On Tue, Sep 6, 2011 at 2:58 PM, Vadim Denisov wrote:
> I install current on last week
> I have s
Sorry about that. It looks like my review must have been missing a line.
@@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx)
_iflib_assert(sctx);
- CTX_LOCK_INIT(ctx, device_get_nameunit(ctx->ifc_dev));
-
+ CTX_LOCK_INIT(ctx);
+ STATE_LOCK_INIT(ctx, device_get_nameunit(c
Actually ctx lock is still a mutex. Just add the STATE_LOCK_INIT line.
-M
On Wed, Apr 11, 2018 at 10:24 AM, K. Macy wrote:
> Sorry about that. It looks like my review must have been missing a line.
>
> @@ -4702,8 +4707,8 @@ iflib_register(if_ctx_t ctx)
>
> _if
Chalk another review fail up to shuffling patches between git and phab.
Sorry for the inconvenience.
-M
On Wed, Apr 11, 2018 at 10:26 AM, K. Macy wrote:
> Actually ctx lock is still a mutex. Just add the STATE_LOCK_INIT line.
> -M
>
> On Wed, Apr 11, 2018 at 10:24 AM, K. Macy wro
1 - 100 of 112 matches
Mail list logo
