[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2] xen{trace/analyze}: don't use 64bit versions of libc functions
El 24/06/15 a les 13.11, Roger Pau Monnà ha escrit: > El 22/06/15 a les 16.48, Roger Pau Monnà ha escrit: >> El 22/06/15 a les 12.09, George Dunlap ha escrit: >>> On 06/22/2015 10:59 AM, Roger Pau Monnà wrote: >>>> El 22/06/15 a les 11.08, George Dunlap ha escrit: >>>>> On 06/19/2015 09:58 AM, Roger Pau Monne wrote: >>>>>> This is not needed, neither encouraged. Configure already checks >>>>>> _FILE_OFFSET_BITS and appends it when needed, so that the right functions >>>>>> are used. Also remove the usage of loff_t and O_LARGEFILE for the same >>>>>> reason. >>>>> >>>>> Just so I understand -- are you saying that configure at the tools >>>>> directory level will notice that Linux can handle 64-bit file operations >>>>> and use them automatically? >>>> >>>> Yes, according to the man page [1]: >>>> >>>> "Over time, increases in the size of the stat structure have led to >>>> three successive versions of stat(): sys_stat() (slot __NR_oldstat), >>>> sys_newstat() (slot __NR_stat), and sys_stat64() (new in kernel 2.4; >>>> slot __NR_stat64). The glibc stat() wrapper function hides these details >>>> from applications, invoking the most recent version of the system call >>>> provided by the kernel, and repacking the returned information if >>>> required for old binaries. Similar remarks apply for fstat() and lstat()." >>> >>> OK, if you can confirm that you've actually tested this on a file larger >>> than 4GiB, then: >> >> No, I have only build tested it since I was trying to unbreak the build. >> I don't think I will have time to test this until tomorrow, sorry for >> the delay. > > I've now tested this with a ~5GB file and it seems to work fine, I > haven't seen any error and the output looks reasonable. This was on a > 64bit Dom0, if someone has a 32bit Dom0 it would be good to test it > there also. I've also tested on a 32bit Dom0, with and without the patches in this series and I always end up getting the same strange output from xenalyze: # xenalyze trace.file No output defined, using summary. Using VMX hardware-assisted virtualization. scan_for_new_pcpu: Activating pcpu 0 at offset 0 Creating vcpu 0 for dom 32768 scan_for_new_pcpu: Activating pcpu 1 at offset 10376 Creating vcpu 1 for dom 32768 scan_for_new_pcpu: Activating pcpu 4 at offset 10848 Creating vcpu 4 for dom 32768 scan_for_new_pcpu: Activating pcpu 6 at offset 11176 Creating vcpu 6 for dom 32768 init_pcpus: through first trace write, done for now. Creating domain 0 Creating vcpu 0 for dom 0 Using first_tsc for d0v0 (8109 cycles) Creating domain 32767 Creating vcpu 1 for dom 32767 Creating vcpu 1 for dom 0 Creating vcpu 2 for dom 0 Creating vcpu 4 for dom 32767 Using first_tsc for d32767v4 (9407 cycles) Creating vcpu 6 for dom 32767 Using first_tsc for d32767v6 (8755 cycles) process_cpu_change: Activating pcpu 5 at offset 16664 Creating vcpu 5 for dom 32768 scan_for_new_pcpu: Activating pcpu 7 at offset 17812 Creating vcpu 7 for dom 32768 Creating vcpu 3 for dom 0 Using first_tsc for d0v3 (3369172 cycles) Creating vcpu 0 for dom 32767 Creating vcpu 6 for dom 0 Creating vcpu 5 for dom 32767 Using first_tsc for d32767v5 (7868 cycles) Creating vcpu 7 for dom 0 Creating vcpu 7 for dom 32767 Using first_tsc for d32767v7 (7693 cycles) process_cpu_change: Activating pcpu 2 at offset 61284 Creating vcpu 2 for dom 32768 process_cpu_change: Activating pcpu 3 at offset 62128 Creating vcpu 3 for dom 32768 Creating vcpu 5 for dom 0 Creating vcpu 3 for dom 32767 Using first_tsc for d32767v3 (24609 cycles) Creating vcpu 4 for dom 0 Creating vcpu 2 for dom 32767 Using first_tsc for d32767v2 (2575 cycles) WARNING: Unexpected vcpu data type for d0v0 on proc 1! Expected 1 got 2. Not processing ] 84007(8:4:7) 0 [ ] WARNING: Unexpected vcpu data type for d0v0 on proc 1! Expected 1 got 2. Not processing ] 84006(8:4:6) 0 [ ] WARNING: Unexpected vcpu data type for d0v2 on proc 6! Expected 1 got 2. Not processing ] 84008(8:4:8) 0 [ ] WARNING: Unexpected vcpu data type for d0v2 on proc 6! Expected 1 got 2. Not processing ] 84008(8:4:8) 0 [ ] WARNING: Unexpected vcpu data type for d0v3 on proc 0! Expected 1 got 2. Not processing ] 84006(8:4:6) 0 [ ] Creating domain 90 Creating vcpu 0 for dom 90 Creating domain 89 Creating vcpu 0 for dom 89 Unknown hvm event: 84011 h->exit_reason 7b > exit_reason_max 38! ] 81002(8:1:2) 2 [ 7b 100d9e ] And that's all. Since this seems to not be related to this fixes I think they should be applied. Roger. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |