From: Joel Soete <soete.joel@tiscali.be>
To: Randolph Chung <randolph@tausq.org>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] 2.6.10-rc1-pa11 profile data
Date: Thu, 11 Nov 2004 18:23:56 +0000 [thread overview]
Message-ID: <4193AE3C.9020509@tiscali.be> (raw)
In-Reply-To: <20041111081154.GR15714@tausq.org>
Randolph Chung wrote:
>>I've collect two profiles for -64SMP and will collect
>>some UP profiles tomorrow. profiles so far are measuring
>>a full kernel build. I expect I'll do the same for -64UP
>>kernels too.
>
>
> hmm.. interesting. top consumers are (with idle loop functions removed)
>
> 40646 flush_kernel_icache_page 406.4600
> 7364 fdsync 368.2000
> 10567 flush_user_dcache_range_asm 293.5278
> 10387 flush_user_icache_range_asm 288.5278
mmm (may be another stupid remarks but) I noticed that:
748 flush_user_dcache_page 7.4800
648 flush_user_icache_page 6.4800
4255 purge_kernel_dcache_page 42.5500
10567 flush_user_dcache_range_asm 293.5278
10387 flush_user_icache_range_asm 288.5278
40646 flush_kernel_icache_page 406.4600
10 flush_kernel_icache_range_asm 0.0862
i.e. flush_kernel_[di]cache_page is few used versus flush_kernel_[di]cache_range_asm while flush_user_[di]cache_range_asm is more
used then flush_user_[di]cache_page.
Isn't it strange?
[...]
mmm also:
49576 machine_restart 774.6250
??
(I don't understand because stat were cleaned "readprofile -r" before the build)
>
> we really need to do better at cache flushing..... anybody have any
> ideas? :)
>
> but looking at the other ones:
> - __clear_user_page_asm can be optimized for 64-bit by writing 8 bytes
> at a time instead of 4
> - _spin_lock* needs investigation to see if we have some bad locks
> someplace. lockmeter anybody?
> - *lclu* can be rewritten to do better than 1-byte at a time
> - copy_user_page_asm can be sped up slightly by using pa_memcpy, but not
> much when i tried last time
> - *lslen* can also probably be written in a smarter way...
>
> i suspect some areas for further investigation are:
> - can we do tlb_flush_mm() in a smarter way for SMP?
> - can we improve kernel entry time for interrupts (and syscalls) by
> being smarter about what we save on the stack? (i.e. only callee-save
> registers and not all the registers?)
>
> volunteers? :)
>
I couldn't realy help more but I will take a look in more details from time to time :)
Thanks,
Joel
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
next prev parent reply other threads:[~2004-11-11 18:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-11 7:54 [parisc-linux] 2.6.10-rc1-pa11 profile data Grant Grundler
2004-11-11 8:11 ` Randolph Chung
2004-11-11 17:39 ` Carlos O'Donell
2004-11-11 17:42 ` Randolph Chung
2004-11-11 17:50 ` Matthew Wilcox
2004-11-11 17:59 ` Randolph Chung
2004-11-11 18:36 ` Grant Grundler
2004-11-11 18:23 ` Joel Soete [this message]
2004-11-11 18:51 ` Randolph Chung
2004-11-26 16:59 ` flush_kernel_[di]cache_page question? [WAS: " Joel Soete
2004-11-26 17:13 ` Randolph Chung
2004-11-26 19:02 ` Grant Grundler
2004-11-28 21:01 ` [id]cache meaning? [Was: [parisc-linux] 2.6.10-rc1-pa11 profile data] Joel Soete
2004-11-28 21:13 ` Matthew Wilcox
2004-11-29 1:14 ` Michael S. Zick
2004-11-29 2:00 ` Matthew Wilcox
2004-12-01 17:44 ` More questions " Joel Soete
2004-12-01 17:56 ` Matthew Wilcox
2004-12-01 18:33 ` Joel Soete
2004-12-03 10:24 ` Joel Soete
2004-12-03 15:41 ` Randolph Chung
2004-12-07 14:42 ` Joel Soete
2004-12-03 15:00 ` *lcul and memory granularity question[Was: " Joel Soete
2004-12-03 15:13 ` Matthew Wilcox
2004-11-12 5:29 ` [parisc-linux] 2.6.10-rc1-pa11 profile data Grant Grundler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4193AE3C.9020509@tiscali.be \
--to=soete.joel@tiscali.be \
--cc=parisc-linux@lists.parisc-linux.org \
--cc=randolph@tausq.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox