kind of rescheduling when TIF_PERFCTR
flag is on?
On 9/1/07, jiaqi zhang <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I'm doing performance experiments of my applications on UltraSparc T1.
> In order to test the data of cache miss or other things, I'm in need
> of some w
Hello,
I'm doing performance experiments of my applications on UltraSparc T1.
In order to test the data of cache miss or other things, I'm in need
of some ways to access PIC and PCR. I wrote a simple module to read
and set these registers using the macros found in
asm-sparc64/system.h. However, no
ain(){
struct timeval begin,end;
register int i,j;
int foo,bar;
int *data=(int *)malloc(100*sizeof(int)*MEGA);
register int *buf, *lastone;
lastone=&data[LASTITEM];
gettimeofday(&begin,NULL);
for(i=0;i wrote:
> From: "jiaqi
Hi, everyone,
I don't really know if it is proper to post this topic here.
In order to accelerate our applications, I adopted the PREFETCH
instruction of UltraSparc. However, the results are not expected: the
one with prefetch works even a little bit slower. The whole program is
listed below.
I r
OK. I'll try that.
Thanks a lot for your valuable help.
On 8/16/07, jiaqi zhang <[EMAIL PROTECTED]> wrote:
> On 8/15/07, David Miller <[EMAIL PROTECTED]> wrote:
>
> >
> > Check the component list from the ALOM prompt.
> >
> Do you mean the "showcom
On 8/15/07, David Miller <[EMAIL PROTECTED]> wrote:
>
> Check the component list from the ALOM prompt.
>
Do you mean the "showcomponent" command? I ran it and got the information:
sc> showcomponent
Keys:
MB/CMP0/P0
MB/CMP0/P1
MB/CMP0/P2
MB/CMP0/P3
MB/CMP0/P4
MB/CMP0/P5
MB/CMP0/P6
M
hanks!
On 8/14/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "jiaqi zhang" <[EMAIL PROTECTED]>
> Date: Tue, 14 Aug 2007 10:51:31 +1200
>
>
> The kernel groups cpus into scheduling groups depending upon
> whether they share execution resources or ca
> You can look at the files under /sys/devices/system/cpu/cpu${ID}/topology/
> to see this information.
However, I find "topology" an empty directory:(
> This datastructure is parsed and managed in arch/sparc64/kernel/mdesc.c,
> in particular you might find mdesc_fill_in_cpu_data() useful.
Howeve
programs. Since we can set the affinity of the processes and cpu, we
want to make it clear which physical core we have binded our processes
to.
Is there any other mechanism in Linux we could utilize to approach this goal?
Thanks.
On 8/14/07, David Miller <[EMAIL PROTECTED]> wrote:
> Fro
Hello, everyone.
Thanks again for the previous help on the faultive instruction
problem. That works perfect:)
Since I have to do some more tests on the cache problem of UltraSPARC
T1, I have to know the exact physical cpu id of each strand. Could
anyone give me some clues on how the physical cpu
Do you mean retrieving the instruction from tpc in sigcontext?
Thanks a lot. I'll try it.
On 8/7/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "jiaqi zhang" <[EMAIL PROTECTED]>
> Date: Tue, 7 Aug 2007 10:41:18 +1200
>
> > While I could find the fau
Hello everyone,
I'm working on a project that needs to deal with SIGSEGV on SPARC64.
While I could find the faultive address in siginfo_t, it seems there
is no way to find the access type(read or write) in it. I tracked the
kernel source and found that ther kernel retrieves this information
(fault
12 matches
Mail list logo
