From: Will C. <wc...@re...> - 2002-08-30 17:30:24
|
I have merged Bob Montgomery's IA64 drivers into the current oprofile CVS. I have put the patch (ia64g.patch) and some information about the IA64 patch support at http://people.redhat.com/wcohen/. The ia64 oprofile support is work in progress. There are a number of known problems with the code (there are problably some unknown problems too): -This code will not work with kernels that do not export the syscall table. -The code will only work with IA64 SMP kernels. -The code needs perfmon support in the kernel. -There are problems with determining the executable name from the mmap information in /proc. The IA64 kernel does not put the executable name as the first entry. -For some kernels the IA64 oprofile module compilation will generate warnings. -OProfile daemon currently only uses the low 32-bits of the address samples may be miss attributed because of the loss of the upper 32-bits of the address. 2002-08-30 Will Cohen <wc...@re...> README: Update contact information. configure.in: Add test for ia64. dae/opd_mapping.c: Change include order. libop++/op_print_event.cpp: Change include order. dae/oprofiled.c (opd_do_samples): Type cast. libop/op_cpu_type.c (cpu_names): Add IA64 to lists. (cpu_nr_counters): Include number of IA64 performance counters. libop/op_cpu_type.h (op_cpu): Add IA64. libop/op_events: Add IA64 flags and events. libop/op_events_desc.c: Describe IA64 events. libop/op_interface.h (op_sample): Allow for 64-bit eip. module/Makefile.in: op_rtc made to target specific. module/op_rtc.c: moved to module/x86/op_rtc.c. module/x86/op_rtc.c: module/op_rtc.c. module/x86/Makefile.in (obj-y): Add op_rtc.o module/oprofile.c (evict_op_entry): Conditionally include x86 code. (op_do_profile): Eliminate regparm3. Get eip and eflags from the appropriate place. Avoid accessing regs where possible. (oprof_read): Return ssize_t. (oprof_init_data): Factor out notebufsize. module/oprofile.h (regparm3): remove, use FASTCALL instead. (INST_PTR): New. (STATUS): New. utils/op_help.c (main): Additions for IA64 manual information. module/ia64/IA64entry.h: New. module/ia64/IA64minstate.h: New. module/ia64/IA64syscallstub.h: New. module/ia64/Makefile: New. module/ia64/Makefile.in: New. module/ia64/cpu_type.c: New. module/ia64/op_apic.c: New. module/ia64/op_pmu.c: New. module/ia64/op_rtc.c: New. module/ia64/op_syscalls.c: New. module/ia64/oprofile_stubs.S: New. |
From: John L. <le...@mo...> - 2002-09-02 12:36:20
|
On Fri, Aug 30, 2002 at 01:30:19PM -0400, Will Cohen wrote: > CVS. I have put the patch (ia64g.patch) and some information about the Thanks. > IA64 patch support at http://people.redhat.com/wcohen/. The ia64 > oprofile support is work in progress. There are a number of known > problems with the code (there are problably some unknown problems too): I hope we can eventually get this stuff into a good enough state to merge into the main tree. I'd rather see some more work on this before merging (Will, if it would be more convenient for you, we could create a branch for you). (it seems that the fake install_nmi is a hangover from the pre-arch-splitup days ??) Is there a reason why there is #ifdef ia64 for the eip in the structures rather than just changing it everywhere to "unsigned long eip" ? > -There are problems with determining the executable name from > the mmap information in /proc. The IA64 kernel does not put > the executable name as the first entry. This isn't guaranteed on any platform. I thought we had fixed this recently... > -OProfile daemon currently only uses the low 32-bits of the > address samples may be miss attributed because of the loss of > the upper 32-bits of the address. Right, we have to fix that too (I guess Dave has done this already ...) > module/oprofile.h (regparm3): remove, use FASTCALL instead. It would be great if you could split little bits like this out as separate patches (e.g. is FASTCALL still there in 2.2 ? Don't remember) regards john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro |
From: Will C. <wc...@re...> - 2002-09-03 14:31:39
|
John Levon wrote: > On Fri, Aug 30, 2002 at 01:30:19PM -0400, Will Cohen wrote: > > >>CVS. I have put the patch (ia64g.patch) and some information about the > > > Thanks. > > >>IA64 patch support at http://people.redhat.com/wcohen/. The ia64 >>oprofile support is work in progress. There are a number of known >>problems with the code (there are problably some unknown problems too): > > > I hope we can eventually get this stuff into a good enough state to > merge into the main tree. I'd rather see some more work on this before > merging (Will, if it would be more convenient for you, we could create a > branch for you). Yes, a cvs branch would make it a bit simpler. Before we create a branch could we put in the changes to use FASTCALL and oprof_read return ssize_t into the CVS repository? I checked and FASTCALL is in the 2.2.0 kernel. ssize_t is used in the declarations of read functions in the 2.2.0 kernel, so there shouldn't be compatibility problems there. I would like to also move op_rtc.c out of the module directory or atleast not compiled at all times. Some targets such as the ia64 do not support RTC in this manner. I moved it into modules/x86. Maybe the more appropriate manner is to have a module/rtc directory used for machines with unsupported performance monitoring hardware, have the op_rtc.c file in there, and have symbolic link from what ever machine specific directory into there, so we don't have multiple copies of the file. > (it seems that the fake install_nmi is a hangover from the > pre-arch-splitup days ?? Yes, the install_nmi stuff should go away. > Is there a reason why there is #ifdef ia64 for the eip in the structures > rather than just changing it everywhere to "unsigned long eip" ? I would like to make eip an "unsigned long eip". I would like to remove as many "#ifdef"s as possible. We should be aware the structure field order causes eip to straddle 64bit words. Could we change the order of fields to make eip 64-bit aligned? On processors 64-bit processors this is going to make accessing eip expensive. >> -There are problems with determining the executable name from >> the mmap information in /proc. The IA64 kernel does not put >> the executable name as the first entry. > > > This isn't guaranteed on any platform. I thought we had fixed this > recently... There have been some changes to help in the regard, but I don't think there has been really a way to test this on x86 machines. From what I have seen on the x86 machines the first entry in mmap list is the executable, so there isn't much difference between the before and after. On the ia64 machine I am using it definitely does not order the mmap entries, so things associating shared library samples with an executable oprofile gets wrong. >> -OProfile daemon currently only uses the low 32-bits of the >> address samples may be miss attributed because of the loss of >> the upper 32-bits of the address. > > > Right, we have to fix that too (I guess Dave has done this already ...) I took a look at Dave's patch and didn't see any obvious changes to support 64-bit addressing. Maybe I overlooked it. >> module/oprofile.h (regparm3): remove, use FASTCALL instead. > > > It would be great if you could split little bits like this out as > separate patches (e.g. is FASTCALL still there in 2.2 ? Don't remember) I will split out the op_read declaration and FAST call out as separate bits. > regards > john > |
From: John L. <le...@mo...> - 2002-09-03 14:38:55
|
On Tue, Sep 03, 2002 at 10:30:04AM -0400, Will Cohen wrote: > Yes, a cvs branch would make it a bit simpler. Before we create a branch > could we put in the changes to use FASTCALL and oprof_read return > ssize_t into the CVS repository? Yes. Please send the two patches with changelogs. Also, how about merging the u32 eip -> unsigned long changes so you can drop all the #ifdef ia64 bits ? > I would like to also move op_rtc.c out of the module directory or > atleast not compiled at all times. Some targets such as the ia64 do not > support RTC in this manner. I moved it into modules/x86. Maybe the more > appropriate manner is to have a module/rtc directory used for machines > with unsupported performance monitoring hardware, have the op_rtc.c file > in there, and have symbolic link from what ever machine specific > directory into there, so we don't have multiple copies of the file. I'm fine with moving it into x86/ for now. We should also change it so that the fallback-to-rtc logic is in x86/ too, so you don't need that fake rtc code in ia64. > I would like to make eip an "unsigned long eip". I would like to remove > as many "#ifdef"s as possible. We should be aware the structure field > order causes eip to straddle 64bit words. Could we change the order of > fields to make eip 64-bit aligned? On processors 64-bit processors this > is going to make accessing eip expensive. Yes, sure. > There have been some changes to help in the regard, but I don't think > there has been really a way to test this on x86 machines. From what I > have seen on the x86 machines the first entry in mmap list is the > executable, so there isn't much difference between the before and after. > On the ia64 machine I am using it definitely does not order the mmap > entries, so things associating shared library samples with an executable > oprofile gets wrong. Apparently /dev/mem is the first mapping with some X processes (not my machine which is why I made the error in the first case). Have you tested current CVS without your change here ? If it's still broken hopefully Phil can find out what's still going wrong. thanks john -- "Take the ideas you find useful. Try not to get hung up on the labels." - Jonathan S. Shapiro |
From: Philippe E. <ph...@wa...> - 2002-09-03 16:12:44
|
John Levon wrote: >On Tue, Sep 03, 2002 at 10:30:04AM -0400, Will Cohen wrote: > > ... >>I would like to also move op_rtc.c out of the module directory or >>atleast not compiled at all times. Some targets such as the ia64 do not >>support RTC in this manner. I moved it into modules/x86. Maybe the more >>appropriate manner is to have a module/rtc directory used for machines >>with unsupported performance monitoring hardware, have the op_rtc.c file >>in there, and have symbolic link from what ever machine specific >>directory into there, so we don't have multiple copies of the file. >> >> > >I'm fine with moving it into x86/ for now. We should also change it so >that the fallback-to-rtc logic is in x86/ too, so you don't need that >fake rtc code in ia64. > I prefer the Will way directly rtc/rtc.c rtc/no_rtc.c and select at configure the right filename, most af architecture are RTC capable and after the ia64 port the only needs to support new arch is to provide the syscall tracking. >>There have been some changes to help in the regard, but I don't think >>there has been really a way to test this on x86 machines. From what I >>have seen on the x86 machines the first entry in mmap list is the >>executable, so there isn't much difference between the before and after. >>On the ia64 machine I am using it definitely does not order the mmap >>entries, so things associating shared library samples with an executable >>oprofile gets wrong. >> >> > >Apparently /dev/mem is the first mapping with some X processes (not my >machine which is why I made the error in the first case). Have you >tested current CVS without your change here ? If it's still broken >hopefully Phil can find out what's still going wrong. > yeps I got this problem on x86 for XFree86, I think the current cvs should handle this case for ia64. regards, Phil |
From: William C. <wc...@nc...> - 2002-09-04 18:14:34
|
John Levon wrote: > On Tue, Sep 03, 2002 at 10:30:04AM -0400, Will Cohen wrote: [snip...] >>There have been some changes to help in the regard, but I don't think >>there has been really a way to test this on x86 machines. From what I >>have seen on the x86 machines the first entry in mmap list is the >>executable, so there isn't much difference between the before and after. >>On the ia64 machine I am using it definitely does not order the mmap >>entries, so things associating shared library samples with an executable >>oprofile gets wrong. > > > Apparently /dev/mem is the first mapping with some X processes (not my > machine which is why I made the error in the first case). Have you > tested current CVS without your change here ? If it's still broken > hopefully Phil can find out what's still going wrong. > > thanks > john > I backed out my change from opd_mapping.c and used the CVS code on the ia64 to see of the mmap problem still existed. The problem for determining the executable name still appears. I turned on "separate samples" in oprof_start to exercise the code, turned on verbose logging, started sampling on the ia64 machine, and started up spec2000. It seems to work for a while, but at some point things go wrong. I did the following to find the mapping information: grep " app " /var/lib/oprofile/oprofiled.log|more Opening image "/boot/vmlinux-2.4.18-e.0.16custom" for app "none" Opening image "/lib/ld-2.2.5.so" for app "/sbin/init" Opening image "/lib/libc-2.2.5.so" for app "/sbin/init" Opening image "/sbin/init" for app "/sbin/init" Opening image "/lib/ld-2.2.5.so" for app "/sbin/dhcpcd" Opening image "/lib/libc-2.2.5.so" for app "/sbin/dhcpcd" Opening image "/lib/libnss_files-2.2.5.so" for app "/sbin/dhcpcd" Opening image "/lib/libnss_nisplus-2.2.5.so" for app "/sbin/dhcpcd" Opening image "/lib/libnsl-2.2.5.so" for app "/sbin/dhcpcd" Opening image "/lib/libnss_dns-2.2.5.so" for app "/sbin/dhcpcd" Opening image "/lib/libresolv-2.2.5.so" for app "/sbin/dhcpcd" ... skip to part where things seems to go wrong ... Opening image "/usr/local/bin/oprofiled" for app "/usr/local/bin/oprofiled" Opening image "/lib/ld-2.2.5.so" for app "/bin/sleep" Opening image "/lib/libm-2.2.5.so" for app "/bin/sleep" Opening image "/lib/librt-2.2.5.so" for app "/bin/sleep" Opening image "/lib/libc-2.2.5.so" for app "/bin/sleep" Opening image "/lib/libpthread-0.9.so" for app "/bin/sleep" Opening image "/bin/sleep" for app "/bin/sleep" Opening image "/lib/ld-2.2.5.so" for app "none" Opening image "/usr/bin/expr" for app "/lib/ld-2.2.5.so" Opening image "/lib/libc-2.2.5.so" for app "/lib/ld-2.2.5.so" Opening image "/root/benchmarks/spec_cpu_2000_v1.1-CDROM/bin/specperl" for app "/lib/ld-2.2.5.so" Opening image "/lib/libnsl-2.2.5.so" for app "/lib/ld-2.2.5.so" Opening image "/usr/lib/libdb2.so.3" for app "/lib/ld-2.2.5.so" Opening image "/usr/lib/libgdbm.so.2.0.0" for app "/lib/ld-2.2.5.so" Opening image "/lib/libdl-2.2.5.so" for app "/lib/ld-2.2.5.so" Opening image "/lib/libm-2.2.5.so" for app "/lib/ld-2.2.5.so" Opening image "/lib/libcrypt-2.2.5.so" for app "/lib/ld-2.2.5.so" Opening image "/root/benchmarks/spec_cpu_2000_v1.1-CDROM/bin/lib/5.00503/ia64-linux/auto/IO/IO.so" for app "/lib/ld-2.2.5.so" Notice that image "/usr/bin/expr" has app "/lib/ld-2.2.5.so" and from then on the app name seems to be wrong most of the time. There is still some problems with the way mapping to executable name is done. Thus, the following ChangeLog entry doesn't fix the problem on ia64 machines. 2002-08-06 Philippe Elie <ph...@wa...> * dae/opd_parse.c: * dae/opd_proc.c: * dae/opd_proc.h: fix #591275 which is a re-hash of #584723 we can now safely assume than proc->maps[0] is the primary image. Problem reported by William cohen -Will |
From: Philippe E. <ph...@wa...> - 2002-09-04 19:26:06
|
William Cohen wrote: > > I backed out my change from opd_mapping.c and used the CVS code on the > ia64 to see of the mmap problem still existed. The problem for > determining the executable name still appears. I turned on "separate > samples" in oprof_start to exercise the code, turned on verbose > logging, started sampling on the ia64 machine, and started up > spec2000. It seems to work for a while, but at some point things go > wrong. I did the following to find the mapping information: > grep " app " /var/lib/oprofile/oprofiled.log|more ... > > ... skip to part where things seems to go wrong ... > Opening image "/bin/sleep" for app "/bin/sleep" > Opening image "/lib/ld-2.2.5.so" for app "none" > Opening image "/usr/bin/expr" for app "/lib/ld-2.2.5.so" > Opening image "/lib/libc-2.2.5.so" for app "/lib/ld-2.2.5.so" > Opening image "/root/benchmarks/spec_cpu_2000_v1.1-CDROM/bin/specperl" > for app "/lib/ld-2.2.5.so" > Opening image "/lib/libnsl-2.2.5.so" for app "/lib/ld-2.2.5.so" > Opening image "/usr/lib/libdb2.so.3" for app "/lib/ld-2.2.5.so" ... > Notice that image "/usr/bin/expr" has app "/lib/ld-2.2.5.so" and from > then on the app name seems to be wrong most of the time. There is > still some problems with the way mapping to executable name is done. > Thus, the following ChangeLog entry doesn't fix the problem on ia64 > machines. things goes wrong from the previous line Opening image "/lib/ld-2.2.5.so" for app "none" unless ld-2.2.5.so is launched as a standalone application can you post all oprofiled.log from: Opening image "/usr/local/bin/oprofiled" for app "/usr/local/bin/oprofiled" to Opening image "/root/benchmarks/spec_cpu_2000_v1.1-CDROM/bin/specperl" for app "/lib/ld-2.2.5.so" if it's really too long http it please. btw, thinking of your previous fix it can't work if the process is already dead so we need to fix it in an another way (process notification can be retained a long time in module, you will probably see problems if you try to profile a script which launch a lot of short time process) Phil |
From: William C. <wc...@nc...> - 2002-09-04 19:50:56
|
The compressed version of the log file is at http://people.redhat.com/wcohen/oprofiled.log.gz Yes, I realized that my previous fix has a problem if the process dies before the daemon get around to recording the data. That is a general problem oprofile has with getting the data from /proc. -Will Philippe Elie wrote: > William Cohen wrote: > >> >> I backed out my change from opd_mapping.c and used the CVS code on the >> ia64 to see of the mmap problem still existed. The problem for >> determining the executable name still appears. I turned on "separate >> samples" in oprof_start to exercise the code, turned on verbose >> logging, started sampling on the ia64 machine, and started up >> spec2000. It seems to work for a while, but at some point things go >> wrong. I did the following to find the mapping information: >> grep " app " /var/lib/oprofile/oprofiled.log|more > > > > ... > >> >> ... skip to part where things seems to go wrong ... > > >> Opening image "/bin/sleep" for app "/bin/sleep" >> Opening image "/lib/ld-2.2.5.so" for app "none" >> Opening image "/usr/bin/expr" for app "/lib/ld-2.2.5.so" >> Opening image "/lib/libc-2.2.5.so" for app "/lib/ld-2.2.5.so" >> Opening image "/root/benchmarks/spec_cpu_2000_v1.1-CDROM/bin/specperl" >> for app "/lib/ld-2.2.5.so" >> Opening image "/lib/libnsl-2.2.5.so" for app "/lib/ld-2.2.5.so" >> Opening image "/usr/lib/libdb2.so.3" for app "/lib/ld-2.2.5.so" > > > ... > >> Notice that image "/usr/bin/expr" has app "/lib/ld-2.2.5.so" and from >> then on the app name seems to be wrong most of the time. There is >> still some problems with the way mapping to executable name is done. >> Thus, the following ChangeLog entry doesn't fix the problem on ia64 >> machines. > > > things goes wrong from the previous line > > Opening image "/lib/ld-2.2.5.so" for app "none" > > unless ld-2.2.5.so is launched as a standalone application > > can you post all oprofiled.log from: > > Opening image "/usr/local/bin/oprofiled" for app "/usr/local/bin/oprofiled" > > to > > Opening image "/root/benchmarks/spec_cpu_2000_v1.1-CDROM/bin/specperl" > for app "/lib/ld-2.2.5.so" > > if it's really too long http it please. > > btw, thinking of your previous fix it can't work if the process is > already dead > so we need to fix it in an another way (process notification can be > retained a > long time in module, you will probably see problems if you try to profile a > script which launch a lot of short time process) > > Phil > > > |
From: Philippe E. <ph...@wa...> - 2002-09-04 22:35:00
Attachments:
ia64_output_maps.diff
|
William Cohen wrote: > The compressed version of the log file is at > http://people.redhat.com/wcohen/oprofiled.log.gz > > Yes, I realized that my previous fix has a problem if the process dies > before the daemon get around to recording the data. That is a general > problem oprofile has with getting the data from /proc. FYI: ASCII added 17791 .... DO_EXEC: pid 17791 .... DO_EXIT: process 17791 we got the process 17791 twice time, one through opd_parse_parse, the second through exec/mmap notification but that's only a potential problem... DO_EXEC: pid 17792 Placing mapping for process 17792: 0x00000000-0x0002c000, off 0x00000000, "/lib/ld-2.2.5.so" at maps pos 0 Opening image "/usr/bin/expr" for app "/lib/ld-2.2.5.so" Placing mapping for process 17792: 0x00000000-0x0000c000, off 0x00000000, "/usr/bin/expr" at maps pos 1 Placing mapping for process 17792: 0x0005c000-0x002c3d28, off 0x00000000, "/lib/libc-2.2.5.so" at maps pos 2 DO_EXIT: process 17792 mapping overlapping at NULL address ? ... DO_EXEC: pid 17794 .... DO_EXEC: pid 17794 twice notification for the same process ? so on module/ia64/op_syscalls.c:oprof_output_maps() is wrong try the attached patch (Not tested nor compiled). Note this don't try address the first problem for process 17791 I hope daemon is suficiently robust to handle it. Phil |
From: William C. <wc...@nc...> - 2002-09-04 18:45:08
Attachments:
order.patch
|
John Levon wrote: > On Tue, Sep 03, 2002 at 10:30:04AM -0400, Will Cohen wrote: [snip...] >>I would like to make eip an "unsigned long eip". I would like to remove >>as many "#ifdef"s as possible. We should be aware the structure field >>order causes eip to straddle 64bit words. Could we change the order of >>fields to make eip 64-bit aligned? On processors 64-bit processors this >>is going to make accessing eip expensive. > > > Yes, sure. Here is what I have to eliminate the #ifdef's between ia64 and ia32 structs. It builds on ia32 (no other changes from cvs) and ia64 (with the patches in earlier email). I changed the order of the fields in op_sample to make sure that eip is aligned. I noticed that struct op_sample is 20 bytes in size for 64-bit platforms. Comments about the patch? 2002-09-04 Will Cohen <wc...@re...> * libop/op_interface.h (op_sample, op_note): Make capatible with 64-bit targets. * dae/opd_proc.c (opd_put_sample): Adjust verbprintf arguments. (opd_handle_fork): Ditto. * dae/oprofiled.c (opd_do_samples): Ditto. -Will |
From: Philippe E. <ph...@wa...> - 2002-09-04 20:05:58
|
William Cohen wrote: > Here is what I have to eliminate the #ifdef's between ia64 and ia32 > structs. It builds on ia32 (no other changes from cvs) and ia64 (with > the patches in earlier email). I changed the order of the fields in > op_sample to make sure that eip is aligned. I noticed that struct > op_sample is 20 bytes in size for 64-bit platforms. Comments about the > patch? with the align(16) it make the struct 32 bytes, with L1 cache line either 64 or 128 bytes, depending on ia64 config, module use 4 or 8 MB for each cpu. It seems a little waht too big at my eyes. I dunno what is the better way to get more sensible value. I'm applying your patch with a TODO entry: o tune memory use for module hash table use for 64 bits architecture, perhaps making the hash table size independant of the cache line size > > 2002-09-04 Will Cohen <wc...@re...> > > * libop/op_interface.h (op_sample, op_note): Make capatible with > 64-bit targets. you mean compatible ? thanks, Phil |
From: William C. <wc...@nc...> - 2002-09-04 21:22:38
|
Yes, I meant "compatible". 4 or 8 MB per processor is kind of large. What was the motivation for splitting up the counter and count? In earlier versions of oprofile those fields took up a single 16-bit field. Any thought of putting counter and count back into a single field? -Will Philippe Elie wrote: > William Cohen wrote: > >> Here is what I have to eliminate the #ifdef's between ia64 and ia32 >> structs. It builds on ia32 (no other changes from cvs) and ia64 (with >> the patches in earlier email). I changed the order of the fields in >> op_sample to make sure that eip is aligned. I noticed that struct >> op_sample is 20 bytes in size for 64-bit platforms. Comments about the >> patch? > > > > with the align(16) it make the struct 32 bytes, with L1 cache line > either 64 or > 128 bytes, depending on ia64 config, module use 4 or 8 MB for each cpu. > It seems > a little waht too big at my eyes. I dunno what is the better way to get > more > sensible value. I'm applying your patch with a TODO entry: > > o tune memory use for module hash table use for 64 bits architecture, > perhaps making > the hash table size independant of the cache line size > >> >> 2002-09-04 Will Cohen <wc...@re...> >> >> * libop/op_interface.h (op_sample, op_note): Make capatible with >> 64-bit targets. > > > > you mean compatible ? > > thanks, > Phil > > > |
From: Philippe E. <ph...@wa...> - 2002-09-04 23:03:38
|
William Cohen wrote: > Yes, I meant "compatible". > > 4 or 8 MB per processor is kind of large. What was the motivation for > splitting up the counter and count? In earlier versions of oprofile > those fields took up a single 16-bit field. Any thought of putting > counter and count back into a single field? pid is now 32 bits for x86 so we can no longer get op_samples 8 bytes length even if we pack field further more we need proper aligment of the hash table to touch only one L1 cache line when we insert a sample in module so now we use 16 bytes op_sample in x86. I think for ia64 we need 32 bytes op_samples so if 8 bytes move are less costly than 4 byte all field would be unsigned long. For the 8 MB byte problems we need probably to use only 1/2 cache line when L1 cache line is 128 bytes. That's tuning and must be do later, for now we have no reference implementation to test change in this area. btw I forgot to commit your last patch (daemon/module interface 64 bits safe) ... It's now comitted regards Phil |
From: Dave J. <da...@su...> - 2002-09-03 16:07:50
|
On Tue, Sep 03, 2002 at 10:30:04AM -0400, Will Cohen wrote: > >> -OProfile daemon currently only uses the low 32-bits of the > >> address samples may be miss attributed because of the loss of > >> the upper 32-bits of the address. > > Right, we have to fix that too (I guess Dave has done this already ...) > I took a look at Dave's patch and didn't see any obvious changes to > support 64-bit addressing. Maybe I overlooked it. I actually missed this (and maybe other similar problems). The 64bit hammer port isn't at a stage where I would see such problems yet. Dave -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs |