Re: RFC: Improving crash's search speed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2011-01-26 at 14:47 +0000, Dave Anderson wrote:

>  
> Anyway, I'm thinking now that "search" should be reworked to add these
> new variants:
> 
>   search -K  unity-mapped kernel only
>   search -V  vmalloc memory only
>   search -M  kernel text/data mapped region (arch-dependent)
>   search -p  physical memory
> 
> and leave the current mechanism as it is now:
> 
>   search -u  user-space of current context 
>   search -k  all of kernel virtual space 
> 
> where "search -k" would be equivalent to "search -KVM".
> 
> Let me tinker around with this -- thanks for the suggestion
> (and the inadvertant x86_64 bug report).

Well, the real reason I started here was that I'm trying to implement my
string searcher, and when I tested the first prototype in crash, it took
forever compared to my physical page searcher.

(Basically a bunch of strncmp's starting on each byte, with extra
searches at the start of the page for "last half or more" and at the end
for "first half or more", since it's hard to track the virtual page
layout to search for strings across page boundaries.)

Today I'm trying to find out why parse_line() is messing up when given
more than one string in ""'s.



Bob Montgomery



--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility


[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux