On 08/22/2010 23:20, Andriy Gapon wrote:
on 23/08/2010 06:17 Doug Barton said the following:
http://people.freebsd.org/~dougb/intr-out-3.txt
So, hm, npviewer.bin eats all the CPU time?
No, the odd bits of that one are the fact that the intr threads irq17,
irq256, and irq20; are showing up
on 23/08/2010 06:17 Doug Barton said the following:
> I also got another interesting set of data today from a "runaway intr"
> situation
> that did not involve swi:4. The symptoms were the same as previously, but the
> devices involved were totally different. This may have to do with the fact
> t
Thanks to help from Andriy I've been working on narrowing down the cause
of my "runaway intr" problems and we've found some interesting things.
First, if I use neither powerd nor set hw.acpi.cpu.cx_lowest less than
C1 things seem to work fine. Using one or the other sort of works, but
between t
On Sun, 22 Aug 2010, Tim Kientzle wrote:
On Aug 22, 2010, at 9:30 AM, Sean C. Farley wrote:
On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote:
Mike Haertel writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks
first for the final letter of the target string, and uses a lookup
On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote:
"Sean C. Farley" writes:
Some algorithms:
1. http://en.wikipedia.org/wiki/Aho-Corasick_string_matching_algorithm
Aho-Corasick is not really a search algorithm, but an algorithm for
constructing a table-driven finite state machine that will mat
Dag-Erling Smørgrav writes:
> Mike Haertel writes:
> > For example if your regex is /foo.*bar/, the initial Boyer-Moore search
> > is (probably) searching for foo.
> >
> > If the initial search succeeds, GNU grep isolates the containing line,
> > and then runs the full regex matcher on that line
Mike Haertel writes:
> For example if your regex is /foo.*bar/, the initial Boyer-Moore search
> is (probably) searching for foo.
>
> If the initial search succeeds, GNU grep isolates the containing line,
> and then runs the full regex matcher on that line to make sure.
You don't really need to "
"Sean C. Farley" writes:
> Some algorithms:
> 1. http://en.wikipedia.org/wiki/Aho-Corasick_string_matching_algorithm
Aho-Corasick is not really a search algorithm, but an algorithm for
constructing a table-driven finite state machine that will match either
of the search strings you fed it. I bel
Dag-Erling Sm�rgrav writes:
> Mike Haertel writes:
> > GNU grep uses the well-known Boyer-Moore algorithm, which looks
> > first for the final letter of the target string, and uses a lookup
> > table to tell it how far ahead it can skip in the input whenever
> > it finds a non-matching character.
On Aug 22, 2010, at 9:30 AM, Sean C. Farley wrote:
> On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote:
>> Mike Haertel writes:
>>> GNU grep uses the well-known Boyer-Moore algorithm, which looks first for
>>> the final letter of the target string, and uses a lookup table to tell it
>>> how far ahe
On 08/22/10 07:10, Dag-Erling Smørgrav wrote:
Nathan Whitehorn writes:
Dag-Erling Smørgrav writes:
I'm not sure I understand what you mean (or rather, how it would
help the tinderbox). What *would* help would be an easy way to
determine, *before* trying to build it, whether a speci
In article <20100822163644.gu2...@hoeg.nl> you write:
>I think that implementing a simple fgrep boils down to mmap()ing a file
>and calling memmem() on the mapping to search for the input string. Of
>course this relies on having an efficient memmem() implementation, for
>example using one of the a
On Aug 22, 2010, at 8:02 AM, Garrett Wollman wrote:
> In article <86k4nikglg@ds4.des.no> you write:
>> Mike Haertel writes:
>>> GNU grep uses the well-known Boyer-Moore algorithm, which looks
>>> first for the final letter of the target string, and uses a lookup
>>> table to tell it how far ah
* Mike Haertel wrote:
> Moreover, GNU grep AVOIDS BREAKING THE INPUT INTO LINES. Looking
> for newlines would slow grep down by a factor of several times,
> because to find the newlines it would have to look at every byte!
I think that implementing a simple fgrep boils down to mmap()ing a file
a
On Sun, 22 Aug 2010, Dag-Erling Smørgrav wrote:
Mike Haertel writes:
GNU grep uses the well-known Boyer-Moore algorithm, which looks first
for the final letter of the target string, and uses a lookup table to
tell it how far ahead it can skip in the input whenever it finds a
non-matching cha
Thank you, I have updated the v15 patch for 8-STABLE.
Dňa 22. 8. 2010 17:44, Olivier Smedts wrote / napísal(a):
> 2010/8/22 Martin Matuska :
>> Dear FreeBSD community,
>>
>> many of our [2] (and Solaris [3]) users today are complaining about slow
>> ZFS writes. One of the causes for these writes
2010/8/22 Dag-Erling Smørgrav :
> Amen. The current bottleneck in BSD grep is the memchr() that looks for
> '\n' in the input buffer.
FYI I actually have a rewritten memchr() which is faster than the
current one here:
http://people.freebsd.org/~delphij/for_review/memchr.c
Review/comments welcom
2010/8/22 Martin Matuska :
> Dear FreeBSD community,
>
> many of our [2] (and Solaris [3]) users today are complaining about slow
> ZFS writes. One of the causes for these writes is the selection of the
> proper allocation method for allocation of new blocks [3] [4]. Another
> issue a write slowdow
In article <86k4nikglg@ds4.des.no> you write:
>Mike Haertel writes:
>> GNU grep uses the well-known Boyer-Moore algorithm, which looks
>> first for the final letter of the target string, and uses a lookup
>> table to tell it how far ahead it can skip in the input whenever
>> it finds a non-mat
Matthias Andree writes:
> Looks a bit like a swing. First we remove Perl from the base system
> (years ago) and move to sed/awk, now we discuss using a scripting
> language in the base system...
Read the discussion from the beginning. We are discussing introducing a
domain-specific scripting la
Dear FreeBSD community,
many of our [2] (and Solaris [3]) users today are complaining about slow
ZFS writes. One of the causes for these writes is the selection of the
proper allocation method for allocation of new blocks [3] [4]. Another
issue a write slowdown during TXG sync times.
Solaris 10 (
On Sat, Aug 21, 2010 at 01:49:45PM -0400, Michael Butler wrote:
> While updating sysutils/coreutils port on -current as of this morning
> (SVN r211550), I noted a panic during the directory rename config test.
>
Your problem seems identical to this report:
http://docs.freebsd.org/cgi/mid.cgi?AAN
TB --- 2010-08-22 11:13:56 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-08-22 11:13:56 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2010-08-22 11:13:56 - cleaning the object tree
TB --- 2010-08-22 11:14:44 - cvsupping the source tree
TB --- 2010-08-22 11:14:44 - /u
Am 22.08.2010 13:21, schrieb Dag-Erling Smørgrav:
> Gabor PALI writes:
>> Dag-Erling Smørgrav writes:
>>> Gabor PALI writes:
Sorry for chiming in, just a quick idea. If you find the "get a
high-level language that compiled to C" idea good,
>>> I don't think it's a good idea
>> Could y
Nathan Whitehorn writes:
> Dag-Erling Smørgrav writes:
> > I'm not sure I understand what you mean (or rather, how it would
> > help the tinderbox). What *would* help would be an easy way to
> > determine, *before* trying to build it, whether a specific kernel
> > config is appropriate for a spe
Mike Haertel writes:
> GNU grep uses the well-known Boyer-Moore algorithm, which looks
> first for the final letter of the target string, and uses a lookup
> table to tell it how far ahead it can skip in the input whenever
> it finds a non-matching character.
Boyer-Moore is for fixed search strin
gahn writes:
> I am running 8.1. under /dev, I don't see /dev/md0,
/dev/md0 won't show up until you actually run mdconfig.
> so i am trying to add following lines in kernel file and got error
> messages:
>
> options MFS #Memory Filesystem
The correct line is "device md",
Randi Harper writes:
> Rui Paulo writes:
> > You are correct. We should not be ejecting the CD without a
> > prompt. If the commit is reverted, it should be explicitly noted in
> > the code so that we don't do this mistake again.
> That's a judgement call, not an absolute. I think what we are doi
Gabor PALI writes:
> Dag-Erling Smørgrav writes:
> > Gabor PALI writes:
> > > Sorry for chiming in, just a quick idea. If you find the "get a
> > > high-level language that compiled to C" idea good,
> > I don't think it's a good idea
> Could you be more specific on your concerns? I am just cur
On Wed, Aug 18, 2010 at 12:48:53PM +0200, Ed Schouten wrote:
> Hi Daichi,
>
> I think Keith Packard of Xorg once wrote a commit message along the
> lines of "5000 lines of code removed, feature added" This seems to be
> similar, albeit on a smaller scale. ;-)
>
> Apart from this issue with unionf
30 matches
Mail list logo
