Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu wrote:
> On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote:
>>
>> I had a problem running the IcedTea java plugin on CURRENT i386, while it
>> works on 8_STABLE.
>> But maybe it's not a problem related to the port.
>> Just to be clear, I'm not looking for a solution about the port here, I'm
>> just
>> wondering why the same c++ code is working on 8_STABLE and it's segfaulting
>> on
>> CURRENT, considering also that AFAIK the gcc version in both the base systems
>> is the same.
>>
>> In the part of the code causing the crash, a std::map is read with an
>> iterator
>> in a for loop, and if a condition is met, an entry is erased.
>> The following is the bt I'm getting:
>> #0 0x29e36247 in kill () from /lib/libc.so.7
>> #1 0x29e361a6 in raise () from /lib/libc.so.7
>> #2 0x282424f6 in XRE_LockProfileDirectory () from
>> /usr/local/lib/firefox3/libxul.so
>> #3
>> #4 0x29c8f1b2 in std::_Rb_tree_increment () from
>> /usr/lib/libstdc++.so.6 #5 0x2ef92402 in
>> IcedTeaPluginUtilities::invalidateInstance () from
>> /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
>> ...
>>
>> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a while
>> and increasing the iterator before erasing from the map, and it seems
>> working.
>> Then I wrote a simple program that do something similar to IcedTea, so there
>> is no need to build the whole java/openjdk6 port to do some testing.
>> Running it on 8_STABLE it works, on CURRENT it crashes.
>> You can find more details in this discussion on the freebsd-java ml:
>> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
>>
>> You can find the patch and the sample code in the discussion above, anyway
>> I'm
>> reporting them here too:
>> icedtea patch:
>> http://pastebin.com/b2KKFNSG
>> test case:
>> http://pastebin.com/Amk4UJ0g
>
> You appear to invalidate the iterator inside the loop and then
> increment it. Do the following:
>
> -- cut here --
> for (iter = cars.begin(); iter != cars.end(); ) {
> if ((*iter).second == modelName)
> cars.erase(iter++);
> else
> ++iter;
> }
> -- and here --
>
> In this example, you first increment the iterator and then erase its
> previous value.
Or, better yet: cars.erase("punto"); I see no reason in iterating
through the whole map unless you want to relate the deletion to the
matched type, in which case you should use the previous example.
--
Good, fast & cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:31 AM, Barbara wrote:
>
>
>>On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote:
>>>
>>> I had a problem running the IcedTea java plugin on CURRENT i386, while it
>>> works on 8_STABLE.
>>> But maybe it's not a problem related to the port.
>>> Just to be clear, I'm not looking for a solution about the port here, I'm
> just
>>> wondering why the same c++ code is working on 8_STABLE and it's segfaulting
> on
>>> CURRENT, considering also that AFAIK the gcc version in both the base
> systems
>>> is the same.
>>>
>>> In the part of the code causing the crash, a std::map is read with an
> iterator
>>> in a for loop, and if a condition is met, an entry is erased.
>>> The following is the bt I'm getting:
>>> #0 0x29e36247 in kill () from /lib/libc.so.7
>>> #1 0x29e361a6 in raise () from /lib/libc.so.7
>>> #2 0x282424f6 in XRE_LockProfileDirectory () from
>>> /usr/local/lib/firefox3/libxul.so
>>> #3
>>> #4 0x29c8f1b2 in std::_Rb_tree_increment () from
>>> /usr/lib/libstdc++.so.6 #5 0x2ef92402 in
>>> IcedTeaPluginUtilities::invalidateInstance () from
>>> /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
>>> ...
>>>
>>> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a
> while
>>> and increasing the iterator before erasing from the map, and it seems
> working.
>>> Then I wrote a simple program that do something similar to IcedTea, so
> there
>>> is no need to build the whole java/openjdk6 port to do some testing.
>>> Running it on 8_STABLE it works, on CURRENT it crashes.
>>> You can find more details in this discussion on the freebsd-java ml:
>>> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
>>>
>>> You can find the patch and the sample code in the discussion above, anyway
> I'm
>>> reporting them here too:
>>> icedtea patch:
>>> http://pastebin.com/b2KKFNSG
>>> test case:
>>> http://pastebin.com/Amk4UJ0g
>>
>>You appear to invalidate the iterator inside the loop and then
>>increment it. Do the following:
>>
>>-- cut here --
>>for (iter = cars.begin(); iter != cars.end(); ) {
>> if ((*iter).second == modelName)
>> cars.erase(iter++);
>> else
>> ++iter;
>>}
>>-- and here --
>>
>>In this example, you first increment the iterator and then erase its
>>previous value.
>>
>
> So there is a bug in my source code! Well, I'm not surprised.
>
> I'm trying to report the code in icedtea here, extracting it from the patch so
> I hope it's accurate enough:
>
> std::map::iterator iterator;
> for (iterator = instance_map->begin(); iterator != instance_map->end();
> iterator++)
> {
> if ((*iterator).second == instance)
> {
> instance_map->erase((*iterator).first);
> }
> }
>
> So, do you think, like Ed Schouten said, that there is a bug in the source
> code but it's just exposed on CURRENT?
> Is that code bad too?
>
> Thanks
> Barbara
>
>
Yes, I believe CURRENT's malloc zeroes out the memory upon deletion,
whereas STABLE doesn't. So in STABLE you get an old copy of the
invalidated iterator, hence it works.
--
Good, fast & cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:32 AM, Vlad Galu wrote:
> On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu wrote:
>> On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote:
>>>
>>> I had a problem running the IcedTea java plugin on CURRENT i386, while it
>>> works on 8_STABLE.
>>> But maybe it's not a problem related to the port.
>>> Just to be clear, I'm not looking for a solution about the port here, I'm
>>> just
>>> wondering why the same c++ code is working on 8_STABLE and it's segfaulting
>>> on
>>> CURRENT, considering also that AFAIK the gcc version in both the base
>>> systems
>>> is the same.
>>>
>>> In the part of the code causing the crash, a std::map is read with an
>>> iterator
>>> in a for loop, and if a condition is met, an entry is erased.
>>> The following is the bt I'm getting:
>>> #0 0x29e36247 in kill () from /lib/libc.so.7
>>> #1 0x29e361a6 in raise () from /lib/libc.so.7
>>> #2 0x282424f6 in XRE_LockProfileDirectory () from
>>> /usr/local/lib/firefox3/libxul.so
>>> #3
>>> #4 0x29c8f1b2 in std::_Rb_tree_increment () from
>>> /usr/lib/libstdc++.so.6 #5 0x2ef92402 in
>>> IcedTeaPluginUtilities::invalidateInstance () from
>>> /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
>>> ...
>>>
>>> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a
>>> while
>>> and increasing the iterator before erasing from the map, and it seems
>>> working.
>>> Then I wrote a simple program that do something similar to IcedTea, so there
>>> is no need to build the whole java/openjdk6 port to do some testing.
>>> Running it on 8_STABLE it works, on CURRENT it crashes.
>>> You can find more details in this discussion on the freebsd-java ml:
>>> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
>>>
>>> You can find the patch and the sample code in the discussion above, anyway
>>> I'm
>>> reporting them here too:
>>> icedtea patch:
>>> http://pastebin.com/b2KKFNSG
>>> test case:
>>> http://pastebin.com/Amk4UJ0g
>>
>> You appear to invalidate the iterator inside the loop and then
>> increment it. Do the following:
>>
>> -- cut here --
>> for (iter = cars.begin(); iter != cars.end(); ) {
>> if ((*iter).second == modelName)
>> cars.erase(iter++);
>> else
>> ++iter;
>> }
>> -- and here --
>>
>> In this example, you first increment the iterator and then erase its
>> previous value.
>
> Or, better yet: cars.erase("punto"); I see no reason in iterating
> through the whole map unless you want to relate the deletion to the
> matched type, in which case you should use the previous example.
>
Sorry, I meant mapped type.
--
Good, fast & cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote:
>
> I had a problem running the IcedTea java plugin on CURRENT i386, while it
> works on 8_STABLE.
> But maybe it's not a problem related to the port.
> Just to be clear, I'm not looking for a solution about the port here, I'm just
> wondering why the same c++ code is working on 8_STABLE and it's segfaulting on
> CURRENT, considering also that AFAIK the gcc version in both the base systems
> is the same.
>
> In the part of the code causing the crash, a std::map is read with an iterator
> in a for loop, and if a condition is met, an entry is erased.
> The following is the bt I'm getting:
> #0 0x29e36247 in kill () from /lib/libc.so.7
> #1 0x29e361a6 in raise () from /lib/libc.so.7
> #2 0x282424f6 in XRE_LockProfileDirectory () from
> /usr/local/lib/firefox3/libxul.so
> #3
> #4 0x29c8f1b2 in std::_Rb_tree_increment () from
> /usr/lib/libstdc++.so.6 #5 0x2ef92402 in
> IcedTeaPluginUtilities::invalidateInstance () from
> /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
> ...
>
> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a while
> and increasing the iterator before erasing from the map, and it seems working.
> Then I wrote a simple program that do something similar to IcedTea, so there
> is no need to build the whole java/openjdk6 port to do some testing.
> Running it on 8_STABLE it works, on CURRENT it crashes.
> You can find more details in this discussion on the freebsd-java ml:
> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
>
> You can find the patch and the sample code in the discussion above, anyway I'm
> reporting them here too:
> icedtea patch:
> http://pastebin.com/b2KKFNSG
> test case:
> http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
--
Good, fast & cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:44 AM, Barbara wrote:
>
>>On Sat, Nov 6, 2010 at 11:31 AM, Barbara wrote:
>>>
>>>
On Sat, Nov 6, 2010 at 10:57 AM, Barbara wrote:
>
> I had a problem running the IcedTea java plugin on CURRENT i386, while it
> works on 8_STABLE.
> But maybe it's not a problem related to the port.
> Just to be clear, I'm not looking for a solution about the port here, I'm
>>> just
> wondering why the same c++ code is working on 8_STABLE and it's
> segfaulting
>>> on
> CURRENT, considering also that AFAIK the gcc version in both the base
>>> systems
> is the same.
>
> In the part of the code causing the crash, a std::map is read with an
>>> iterator
> in a for loop, and if a condition is met, an entry is erased.
> The following is the bt I'm getting:
> #0 0x29e36247 in kill () from /lib/libc.so.7
> #1 0x29e361a6 in raise () from /lib/libc.so.7
> #2 0x282424f6 in XRE_LockProfileDirectory () from
> /usr/local/lib/firefox3/libxul.so
> #3
> #4 0x29c8f1b2 in std::_Rb_tree_increment () from
> /usr/lib/libstdc++.so.6 #5 0x2ef92402 in
> IcedTeaPluginUtilities::invalidateInstance () from
> /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
> ...
>
> I wrote a "patch" for the IcedTea plugin, replacing the for loop with a
>>> while
> and increasing the iterator before erasing from the map, and it seems
>>> working.
> Then I wrote a simple program that do something similar to IcedTea, so
>>> there
> is no need to build the whole java/openjdk6 port to do some testing.
> Running it on 8_STABLE it works, on CURRENT it crashes.
> You can find more details in this discussion on the freebsd-java ml:
> http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
>
> You can find the patch and the sample code in the discussion above,
> anyway
>>> I'm
> reporting them here too:
> icedtea patch:
> http://pastebin.com/b2KKFNSG
> test case:
> http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
>>>
>>> So there is a bug in my source code! Well, I'm not surprised.
>>>
>>> I'm trying to report the code in icedtea here, extracting it from the patch
> so
>>> I hope it's accurate enough:
>>>
>>> std::map::iterator iterator;
>>> for (iterator = instance_map->begin(); iterator != instance_map->end();
>>> iterator++)
>>> {
>>> if ((*iterator).second == instance)
>>> {
>>> instance_map->erase((*iterator).first);
>>> }
>>> }
>>>
>>> So, do you think, like Ed Schouten said, that there is a bug in the source
>>> code but it's just exposed on CURRENT?
>>> Is that code bad too?
>>>
>>> Thanks
>>> Barbara
>>>
>>>
>>
>>Yes, I believe CURRENT's malloc zeroes out the memory upon deletion,
>>whereas STABLE doesn't. So in STABLE you get an old copy of the
>>invalidated iterator, hence it works.
>>
>
> Very nice explanation.
>
> Thanks
>
>
I hope I'm right, I don't have CURRENT installed, it's just an
assumption. However, the C++ code is most definitely buggy.
--
Good, fast & cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
On Sep 27, 2011, at 8:50 PM, Gleb Kurtsou wrote: > On (26/09/2011 23:03), Ade Lovett wrote: >> With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be >> expected, ports/ is going to be essentially unusable for a while. >> >> The issue stems from configure scripts (to choose something completely >> at random) assuming that FreeBSD would never jump to a double-digit >> major version number, and as such, various regexps for "freebsd1*" (ie: >> FreeBSD 1.1.x) are now matching "freebsd10". > > It's more exciting than that. FreeBSD >= 10 is already seized by > Apple :) > > http://www.google.com/codesearch#search/&q=__FreeBSD__%5CW%2B10&type=cs > That seems to be a FUSE-ism. __FreeBSD__ isn't defined anywhere on my OSX system.___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-BETA3 Available...
On Tue, Oct 4, 2011 at 10:38 PM, Arnaud Lacombe wrote: > Hi, > > On Tue, Oct 4, 2011 at 5:30 PM, Joshua Boyd wrote: >> On Tue, Oct 4, 2011 at 4:56 PM, Arnaud Lacombe wrote: >>> >>> Had you loved so much to have this information, you would have given >>> me credential. >>> >>> I may have filled in all the date from publicly available material, >>> might it be from mailing list, or from FTP server's timestamp, or SVN >>> revision date. If I had not been able to determine a date, I may just >>> have left it blank and asked for details, eventually. >>> >>> Unfortunately, we will never know. >> >> It's nice that you want to help, but could you be less of a jerk about it to >> the people who devote a huge amount of time to the project? >> > Which ones: > - those who do not upgrade release information in release cycle ? > - those who commit broken stuff ? > - those who knowingly misdocument interfaces ? > - those who ignore obvious fixes ? > - those who ignore users request ? > - those who ignore users bugs ? > - those who refuses to share their work-in-progress ? > - those who tell you you're wrong for months to finally acknowledge > you are right, and commit your fixes ? Arnaud, everybody is doing their best. If members or groups within the FreeBSD project are under contractual obligation to meet your expectations, please feel free to take this off-list. Otherwise, if you feel there are similar projects with better management, perhaps they're better suited for you. -- Good, fast & cheap. Pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Netmap for routers (em0 device)
On Nov 4, 2011, at 4:06 PM, Archy Cho wrote: > Hello > > I am very happy to see freebsd could have such network performance with > netmap , > since I am currently using freebsd as core routers instead of cisco. > > I tried to re-compile the freebsd 8.2 kernel to test , > however , I could not complete the task ( both i386 and amd64 ), > I could only success at 9.0-RC-1. > > Here is my task and error message, > > cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/Netmap-Router > echo "device netmap" >> /usr/src/sys/i386/conf/Netmap-Router > cd /tmp/netmap/sys/ > cp -R * /usr/src/sys/ > cd /usr/src/ > patch -p < /tmp/netmap/head-netmap.diff > echo "WITHOUT_MODULES = bge re igb" >> /etc/make.conf > make buildkernel KERNCONF=Netmap-Router > make installkernel KERNCONF=Netmap-Router > > -Werror ../../../dev/e1000/if_em.c -I../../../dev/e1000 > ../../../dev/e1000/if_em.c: In function 'em_setup_receive_ring': > ../../../dev/e1000/if_em.c:4012: error: 'j' undeclared (first use in this > function) > ../../../dev/e1000/if_em.c:4012: error: (Each undeclared identifier is > reported only once > ../../../dev/e1000/if_em.c:4012: error: for each function it appears in.) > *** Error code 1 > > Stop in /usr/src/sys/i386/compile/Netmap-Router > > > Any hint of error message ? > It's fairly easy to remove the offending code, AFAIK there were a few unused variable and signed vs unsigned comparisons. > More questions , > I seldom facing DDOS , whatever using polling or not , > 1Gbps link with 64bytes packet will cause CPU 100% , > if a freebsd box compile with netmap , > could it have performance boost of routed / ipfw / pf ? Not yet. In order to do that, ipfw or pf need to be ported to userspace. I believe that was on Luigi's agenda, though. -- Good, fast & cheap: pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Introducing netmap: line-rate packet send/receive at 10Gbit/s
On Fri, Jun 3, 2011 at 12:31 AM, Luigi Rizzo wrote: > Hi, > we have recently worked on a project, called netmap, which lets > FreeBSD send/receive packets at line rate even at 10 Gbit/s with > very low CPU overhead: one core at 1.33 GHz does 14.88 Mpps with a > modified ixgbe driver, which gives plenty of CPU cycles to handle > multiple interface and/or do useful work (packet forwarding, analysis, > etc.) > > You can find full documentation and source code and even a picobsd image at > >http://info.iet.unipi.it/~luigi/netmap/ > > The system uses memory mapped packet buffers to reduce the cost of > data movements, but this would not be enough to make it useful or > novel. Netmap uses many other small but important tricks to make > the system fast, safe and easy to use, and support transmission, > reception, and communication with the host stack. > > You can see full details in documentation at the above link. > > Feedback welcome. > >cheers >luigi > -+--- > Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/. Universita` di Pisa > TEL +39-050-2211611 . via Diotisalvi 2 > Mobile +39-338-6809875 . 56122 PISA (Italy) > -+--- > This is great news, Luigi! Thank you for your work! -- Good, fast & cheap. Pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Heavy I/O blocks FreeBSD box for several seconds
On Thu, Jul 7, 2011 at 5:14 PM, Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > On Thu, Jul 07, 2011 at 10:27:53AM +0300, Andriy Gapon wrote: > > on 06/07/2011 21:11 Nathan Whitehorn said the following: > > > On 07/06/11 13:00, Steve Kargl wrote: > > >> AFAICT, it is a cpu affinity issue. If I launch n+1 MPI images > > >> on a system with n cpus/cores, then 2 (and sometimes 3) images > > >> are stuck on a cpu and those 2 (or 3) images ping-pong on that > > >> cpu. I recall trying to use renice(8) to force some load > > >> balancing, but vaguely remember that it did not help. > > > > > > I've seen exactly this problem with multi-threaded math libraries, as > well. > > > > Exactly the same? Let's see. > > > > > Using parallel GotoBLAS on FreeBSD gives terrible performance because > the > > > threads keep migrating between CPUs, causing frequent cache misses. > > > > So Steve reports that if he has Nthr > Ncpu, then some threads are > "over-glued" > > to a particular CPU, which results in sub-optimal scheduling for those > threads. > > I have to guess that Steve would want to see the threads being shuffled > between > > CPUs to produce more even CPU load. > > I'm using OpenMPI. These are N > Ncpu processes not threads, and without > the loss of generality let N = Ncpu + 1. It is a classic master-slave > situation where 1 process initializes all others. The n-1 slave processes > are then independent of each other. After 20 minutes or so of number > crunching, each slave sends a few 10s of KB of data to the master. The > master collects all the data, writes it to disk, and then sends the > slaves the next set of computations to do. The computations are nearly > identical, so each slave finishes it task in the same amount of time. The > problem appears to be that 2 slaves are bound to the same cpu and the > remaining N - 3 slaves are bound to a specific cpu. The N - 3 slaves > finish their task, send data to the master, and then spin (chewing up > nearly 100% cpu) waiting for the 2 ping-ponging slaves to finishes. > This causes a stall in the computation. When a complete computation > takes days to complete, theses stall become problematic. So, yes, I > want the processes to get a more uniform access to cpus via migration > to other cpus. This is what 4BSD appears to do. > > Spinning threads are a PITA for any scheduler, it's just that in your case 4BSD computes quantums differently. Is there any way to make the software sleep instead of spinning? > > On the other hand, you report that your threads keep being shuffled > between CPUs > > (I presume for Nthr == Ncpu case, where Nthr is a count of the > number-crunching > > threads). And I guess that you want them to stay glued to particular > CPUs. > > > > So how is this the same problem? In fact, it sounds like somewhat > opposite. > > The only thing in common is that you both don't like how ULE works. > > Well, it may be similar in that N - 2 threads are bound to N - 2 > cpus, and the remaining 2 threads are ping ponging on the last > remaining cpu. I suspect that GotoBLAS has a large amount > communication between threads, and once again the computations > stalls waiting of the 2 threads to either finish battling for the > 1 cpu or perhaps the process uses pthread_yield() in some clever > way to try to get load balancing. > > -- > Steve > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Good, fast & cheap. Pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: em problem in virtualbox since the weekend
On Wed, Jul 20, 2011 at 10:59 AM, Nikos Vassiliadis wrote: > On 7/20/2011 5:35 AM, Steve Wills wrote: > >> While testing some other things, I found -CURRENT from yesterday doesn't >> work with the em0 in my VirtualBox 4.0.8 (a little out of date >> admittedly). It worked Friday or Saturday I think. Anyone else seen this >> > > I also see this on a 4.0.4something installation. > > > em0: Unable to allocate bus resource: memory >> em0: Allocation of PCI resources failed >> > > So, you're not alone:) > > Nikos > > Same here. I've tried all possible NIC emulations to no avail. -- Good, fast & cheap. Pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: High Network Perfomance
On Fri, Aug 5, 2011 at 5:03 PM, Andriy Gapon wrote: > on 05/08/2011 17:56 Luigi Rizzo said the following: >> i asked permission to re@ to integrate it in 9.0 but it was considered >> a bit premature. >> However i am not too worried because the system dependencies are >> minimal and it changes no API/ABI or internal data structure so >> it is easy to add it at a later time. > > /rant > > I think that having real, useful in practice applications that make use of the > netmap would definitely speed up its adoption. > > Maybe I am too pessimistic here, but I don't foresee too many users of netmap > as > long as it remains just a mechanism that potentially can greatly speed up > things > if you manage to write your own applications that do those things via netmap. > Full TCP/IP stack with sockets API on top of it and lots of available > applications > on top of that is one thing, an interface to a network card is a totally > different > thing on a scale of usability (especially the by the end-users). Netmap's scope may be narrow, but it's a great alternative to proprietary implementations that are provided by only a handful of vendors and tied to their hardware. I don't think Luigi foresees lots of users either, but having it in the base system is a lot better than not having it at all, IMHO. > > -- > Andriy Gapon > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Good, fast & cheap. Pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: High Network Perfomance
On Fri, Aug 5, 2011 at 5:34 PM, Andriy Gapon wrote: > on 05/08/2011 18:23 Vlad Galu said the following: >> Netmap's scope may be narrow, but it's a great alternative to >> proprietary implementations that are provided by only a handful of >> vendors and tied to their hardware. I don't think Luigi foresees lots >> of users either, but having it in the base system is a lot better than >> not having it at all, IMHO. > > No doubt. > > On the other hand, it was a little bit misleading of Luigi to suggest netmap > to a > user who merely asked about tuning FreeBSD network (routing/firewall) > performance :-) > > netmap can no doubt be useful, but perhaps let's not overhype it before it > actually proves itself on practical tasks. Or has it already? I might have > missed that. It's great for IDS/IPS, which is exactly what I'm using it for :) > > -- > Andriy Gapon > -- Good, fast & cheap. Pick any two. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
