[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.