Hi all,
I am sending some modifications about smaps PATCH.
BTW, thanks Hugh by all your suggestions. The page_table_lock was
already included in the smaps.
BR,
Mauricio Lin.
diff -uprN linux-2.6.11-rc4-bk9/Documentation/filesystems/proc.txt
linux-2.6.11-rc4-bk9-smaps/Documentation/filesystems
On Thu, 3 Mar 2005, Mauricio Lin wrote:
>
> How about map an unmap each pte?
>
> I mean remove the pte++ and use pte_offset_map for each incremented
> address and then pte_unmap. So each incremented address is an index to
> get the next pte via pte_offset_map.
We're going round in circles.
No.
Hi Hugh,
How about map an unmap each pte?
I mean remove the pte++ and use pte_offset_map for each incremented
address and then pte_unmap. So each incremented address is an index to
get the next pte via pte_offset_map.
BR,
Mauricio Lin.
On Wed, 2 Mar 2005 19:07:15 + (GMT), Hugh Dickins <[EM
On Wed, 2 Mar 2005, Mauricio Lin wrote:
> Does anyone know if the place I put pte_unmap is logical and safe
> after several pte increments?
The place is logical and safe, but it's still not quite right.
You should have found several examples of loops having the same
problem, and what do they do? .
Does anyone know if the place I put pte_unmap is logical and safe
after several pte increments?
pte = pte_offset_map(pmd, address);
address &= ~PMD_MASK;
end = address + size;
if (end > PMD_SIZE)
end = PMD_SIZE;
do {
pte_t pag
Hi,
Here are some values about the experiments. The values are the elapsed
real time used by the process, in seconds. Each row corresponds to
1 cat /proc/pid/smaps command.
Old smaps
19.41
19.31
21.38
20.16
New smaps
16.82
16.75
16.75
16.79
BR,
Mauricio Lin.
On Tue, 1 Mar 2005 10:17:56 -
Hi,
> The most important thing about a /proc file format is that it has
> a documented means of being extended in the future. Without such
> documentation, it is impossible to write a reliable parser.
>
> The "Name: value" stuff is rather slow. Right now procps (ps, top, etc.)
> is using a perfe
Well,
It is working better now. You are right Hugh. Now the new version is
faster than the old one. I removed the struct page and its related
function.
Thanks,
BR,
Mauricio Lin.
On Tue, 1 Mar 2005 04:08:15 -0400, Mauricio Lin <[EMAIL PROTECTED]> wrote:
> On Mon, 28 Feb 2005 20:41:31 + (GMT
On Mon, 28 Feb 2005 20:41:31 + (GMT), Hugh Dickins <[EMAIL PROTECTED]>
wrote:
> On Mon, 28 Feb 2005, Mauricio Lin wrote:
> >
> > Now I am testing with /proc/pid/smaps and the values are showing that
> > the old one is faster than the new one. So I will keep using the old
> > smaps version.
>
On Mon, 28 Feb 2005, Mauricio Lin wrote:
>
> Now I am testing with /proc/pid/smaps and the values are showing that
> the old one is faster than the new one. So I will keep using the old
> smaps version.
Sorry, I don't have time for more than the briefest look.
It appears that your old resident_m
Hi,
Just some explanation about the mistake.
I have put cat /proc/pid/status instead of /proc/pid/smaps.
So I was testing the /proc/pid/status and not the /proc/pid/smaps.
Now I am testing with /proc/pid/smaps and the values are showing that
the old one is faster than the new one. So I will kee
Hi all,
I comitted a mistake. Indeed the old smaps is still faster than new one.
Take a look:
Old smaps
real 19.52
user 2.15
sys 17.27
New smaps
real 25.93
user 3.19
sys 22.31
Any comments
BR,
Mauricio Lin.
On Fri, 25 Feb 2005 11:14:36 -0400, Mauricio Lin <[EMAIL PROTECTED]> wrote:
> Hi
Hi all,
I tested the two smaps entry using time command.
I tested 100.000 cat commands with smaps for each version.
I checked the difference between the two versions and the new one is
faster than old one. So Hugh is correct about the loop performance.
Thanks!!!
Mauricio Lin.
On Thu, 24 Feb 2
[quoting various people...]
> Here is a new entry developed for /proc that prints for each process
> memory area (VMA) the size of rss. The maps from original kernel is
> able to present the virtual size for each vma, but not the physical
> size (rss). This entry can provide an additional in
Mauricio Lin <[EMAIL PROTECTED]> wrote:
>
> But can i use jiffies to measure this kind of performance??? AFAIK, if
> it is more efficient, then it is faster, right? How can I know how
> fast it is? Any idea?
umm,
time ( for i in $(seq 100); do; cat /proc/nnn/smaps; done > /dev/null )
?
-
To u
Hi Andrew,
But can i use jiffies to measure this kind of performance??? AFAIK, if
it is more efficient, then it is faster, right? How can I know how
fast it is? Any idea?
BR,
Mauricio Lin.
On Thu, 24 Feb 2005 01:09:47 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Mauricio Lin <[EMAIL PROTE
Mauricio Lin <[EMAIL PROTECTED]> wrote:
>
> You said that the old smaps version is not efficient because the way
> it access each pte.
Nick is talking about changing the kenrel so that it "refcounts pagetable
pages". I'm not sure why.
I assume that this means that each pte page's refcount will
Hi Hugh,
You said that the old smaps version is not efficient because the way
it access each pte. So I changed it using pdg_range, pud_range,
pmd_range and pte_range. Now I am trying to measure the efficiency
between the old and new smaps but something is wrong.
I put some timers before and afte
Hi All,
Here goes the new smaps patch. As suggested by Hugh in another discussion, the
inefficient loop was removed and replaced by smaps_pgd_range,
smaps_pud_range, smaps_pmd and smaps_pte_range functions. I mantained
the old resident_mem_size function between comments just for anyone
who wants
Hi Tosatti and Andrew,
On Mon, 17 Jan 2005 15:30:23 -0200, Marcelo Tosatti
<[EMAIL PROTECTED]> wrote:
>
> Hi Mauricio,
>
> You want to update your patch to handle the new 4level pagetables which
> introduces
> a new indirection table: the PUD.
Here goes the smaps patch updated for kernel 2.6.1
Nick Piggin wrote:
William Lee Irwin III wrote:
It also is used in a particular euphemism that made
it seem odd to me. I suspect it wasn't thought of when it was chosen.
No. What's the euphemism?
... a few private responses later...
Thanks for the enlightenment, everyone. Next time I won't ask
William Lee Irwin III wrote:
On Mon, Jan 17, 2005 at 03:30:23PM -0200, Marcelo Tosatti wrote:
You want to update your patch to handle the new 4level pagetables
which introduces a new indirection table: the PUD.
Check 2.6.11-rc1 - mm/rmap.c.
BTW: What does PUD stand for?
Page Upper Directory.
Tha
On Mon, Jan 17, 2005 at 03:30:23PM -0200, Marcelo Tosatti wrote:
> You want to update your patch to handle the new 4level pagetables
> which introduces a new indirection table: the PUD.
> Check 2.6.11-rc1 - mm/rmap.c.
> BTW: What does PUD stand for?
Page Upper Directory. It also is used in a part
Hi Tosatti,
On Mon, 17 Jan 2005 15:30:23 -0200, Marcelo Tosatti
<[EMAIL PROTECTED]> wrote:
>
> Hi Mauricio,
>
> On Mon, Jan 17, 2005 at 03:02:14PM -0400, Mauricio Lin wrote:
> > Hi Andrew,
> >
> > I figured out the error. This patch works for others editors as well.
>
>
>
> > diff -uprN linu
Hi Mauricio,
On Mon, Jan 17, 2005 at 03:02:14PM -0400, Mauricio Lin wrote:
> Hi Andrew,
>
> I figured out the error. This patch works for others editors as well.
> diff -uprN linux-2.6.10/fs/proc/task_mmu.c
> linux-2.6.10-smaps/fs/proc/task_mmu.c
> --- linux-2.6.10/fs/proc/task_mmu.c 2004-
Hi Andrew,
I figured out the error. This patch works for others editors as well.
diff -uprN linux-2.6.10/Documentation/filesystems/proc.txt
linux-2.6.10-smaps/Documentation/filesystems/proc.txt
--- linux-2.6.10/Documentation/filesystems/proc.txt 2004-12-24
17:34:29.0 -0400
+++ linux-
Hi Andrew,
Sorry for the patch errors.
Here goes the fixed patch. I used the xemacs editor for copying it.
The others editor (emacs and pico) I tried do not copy the patch
rightly. The patch copying also does not work with webmail.
diff -uprN linux-2.6.10/Documentation/filesystems/proc.txt
linux
27 matches
Mail list logo
