Re: kernel
look at http://www.kernelnewbies.org
also it has a section on books. you can also use IRC #kernelnewbies
On 8/25/05, Shwetha V <[EMAIL PROTECTED]> wrote:
>
> Could anyone inform which will be a good guide to start learning the linux
> kernel programming.
>
> --
> Shwetha V
> Software Engineer - Networks Business Unit
> Sasken Communication Technologies Ltd.
> Gold Hill Square, Hosur Road, Bangalore.
> Ph: +91-80-25355501 Ext: 5799
> Web: www.sasken.com
>
>
> "Srinivas K" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > hi friends,
> >
> > post concepts regarding linux kernel which will be useful
> >
> >
> > --
> > Srinivasa Rao K
> > Systems Engineer
> > Nortel Business Unit
> > Sasken Communication Technologies Ltd
> > 139/25, Ring Road, Domlur
> > Bangalore - 560 071
> > Ph: 2535 5501 Extn.:4804
> > mail : [EMAIL PROTECTED]
> >
> > "SASKEN RATED THE BEST EMPLOYER IN THE COUNTRY by the BUSINESS TODAY
> > Mercer
> > Survey 2004"
> >
> >
> > SASKEN BUSINESS DISCLAIMER
> > This message may contain confidential, proprietary or legally Privileged
> > information. In case you are not the original intended Recipient of the
> > message, you must not, directly or indirectly, use, Disclose, distribute,
> > print, or copy any part of this message and you are requested to delete it
> > and inform the sender. Any views expressed in this message are those of
> > the
> > individual sender unless otherwise stated. Nothing contained in this
> > message
> > shall be construed as an offer or acceptance of any offer by Sasken
> > Communication Technologies Limited ("Sasken") unless sent with that
> > express
> > intent and with due authority of Sasken. Sasken has taken enough
> > precautions
> > to prevent the spread of viruses. However the company accepts no liability
> > for any damage caused by any virus transmitted by this email
> >
> >
>
>
>
> "SASKEN RATED THE BEST EMPLOYER IN THE COUNTRY by the BUSINESS TODAY Mercer
> Survey 2004"
>
>
>SASKEN BUSINESS DISCLAIMER
> This message may contain confidential, proprietary or legally Privileged
> information. In case you are not the original intended Recipient of the
> message, you must not, directly or indirectly, use, Disclose, distribute,
> print, or copy any part of this message and you are requested to delete it
> and inform the sender. Any views expressed in this message are those of the
> individual sender unless otherwise stated. Nothing contained in this message
> shall be construed as an offer or acceptance of any offer by Sasken
> Communication Technologies Limited ("Sasken") unless sent with that express
> intent and with due authority of Sasken. Sasken has taken enough precautions
> to prevent the spread of viruses. However the company accepts no liability
> for any damage caused by any virus transmitted by this email
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel
look at http://www.kernelnewbies.org also it has a section on books. you can also use IRC #kernelnewbies On 8/25/05, Shwetha V [EMAIL PROTECTED] wrote: Could anyone inform which will be a good guide to start learning the linux kernel programming. -- Shwetha V Software Engineer - Networks Business Unit Sasken Communication Technologies Ltd. Gold Hill Square, Hosur Road, Bangalore. Ph: +91-80-25355501 Ext: 5799 Web: www.sasken.com Srinivas K [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] hi friends, post concepts regarding linux kernel which will be useful -- Srinivasa Rao K Systems Engineer Nortel Business Unit Sasken Communication Technologies Ltd 139/25, Ring Road, Domlur Bangalore - 560 071 Ph: 2535 5501 Extn.:4804 mail : [EMAIL PROTECTED] SASKEN RATED THE BEST EMPLOYER IN THE COUNTRY by the BUSINESS TODAY Mercer Survey 2004 SASKEN BUSINESS DISCLAIMER This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email SASKEN RATED THE BEST EMPLOYER IN THE COUNTRY by the BUSINESS TODAY Mercer Survey 2004 SASKEN BUSINESS DISCLAIMER This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.
Hello All, Really thankful for your inputs! > Itanium instruction set is not as compact as some other architectures, > so the same program will typically require more bytes of code. I stopped the program on both amd64 machine and ia64 machine and grepped the values from /proc/<>/status and found the following.VmSize: 126304 kB VmLck: 0 kB VmRSS: 6352 kB VmData:19696 kB VmStk:16 kB VmExe: 97760 kB VmLib: 3152 kB <> <--AMD64-> VmSize: 100432 kB VmLck: 0 kB VmRSS: 2828 kB VmData:24428 kB VmStk: 264 kB VmExe: 62848 kB VmLib: 3048 kB <---> Seems like most of core size(VmSize) on ipf (126MB) is coming from the code size(VmExe) i.e 97MB. While the code size is just 62MB on amd64. Looks like IA-64 wastes a lot of VM due to big instruction sizes, so big instruction sizes will improve performance ? compared small instruction sizes? , but fetching big instructions surely takes time compared to small, this may be the reason why amd64 is the fasttest 64-bit process ? Thanks a lot! Vamsi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Multiple virtual address mapping for the same code on IA-64 linux kernel.
Hello All, Sorry to interrupt you. I have been investigating a problem in which there has been a dramatic core size (complete program size) of a program running on a IA-64 machine running kernel version 2.4.21-4.0.1 (A redhat advanced server distribution) compared to other 64-bit architectures like amd64 and EM64T. There has been an increase of around 20% of the size. I verified the virtual address mappings in /proc/<>/maps file and found that several .so files (other segments of same size) are getting mapped multiple times as follows. <> 2005c000-2007c000 r-xp 08:07 6521003 /usr/X11R6/lib/libXext.so.6.4 2007c000-2009 rw-p 0001 08:07 6521003 /usr/X11R6/lib/libXext.so.6.4 2009-20268000 r-xp 08:07 6520995 /usr/X11R6/lib/libX11.so.6.2 20268000-2027 ---p 001d8000 08:07 6520995 /usr/X11R6/lib/libX11.so.6.2 2027-20284000 rw-p 001d 08:07 6520995 /usr/X11R6/lib/libX11.so.6.2 20284000-2028c000 r-xp 08:07 6094863 /lib/libdl-2.2.4.so 2028c000-20294000 ---p 8000 08:07 6094863 /lib/libdl-2.2.4.so 20294000-2029c000 rw-p 08:07 6094863 /lib/libdl-2.2.4.so 2029c000-202b8000 r-xp 08:07 6094883 /lib/libpthread-0.9.so 202b8000-202bc000 ---p 0001c000 08:07 6094883 /lib/libpthread-0.9.so 202bc000-202d4000 rw-p 0001 08:07 6094883 /lib/libpthread-0.9.so 202d4000-20358000 r-xp 08:07 376886 /usr/lib/libncurses.so.5.2 20358000-20364000 ---p 00084000 08:07 376886 /usr/lib/libncurses.so.5.2 20364000-20374000 rw-p 0008 08:07 376886 /usr/lib/libncurses.so.5.2 20374000-20378000 rw-p 00:00 0 20378000-2040 r-xp 08:07 6094865 /lib/libm-2.2.4.so 2040-20408000 ---p 00088000 08:07 6094865 /lib/libm-2.2.4.so 20408000-20414000 rw-p 0008 08:07 6094865 /lib/libm-2.2.4.so 20414000-2065c000 r-xp 08:07 6094859 /lib/libc-2.2.4.so 2065c000-20664000 ---p 00248000 08:07 6094859 /lib/libc-2.2.4.so 20664000-20678000 rw-p 0024 08:07 6094859 /lib/libc-2.2.4.so <---> example /lib/libc-2.2.4.so size 6094859got mapped 3 times with permissions 'r-xp' , '---p' and 'rw-p' from the bottom. I found the similar mappings for all the programs running on a IA-64 machine. Is this some special kernel kind of feature on IA-64 ?? Your kind inputs on this problem are greatly appreciated. Looking forward to hear from you. Thanks in advance, Vamsi kundeti - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Multiple virtual address mapping for the same code on IA-64 linux kernel.
Hello All, Sorry to interrupt you. I have been investigating a problem in which there has been a dramatic core size (complete program size) of a program running on a IA-64 machine running kernel version 2.4.21-4.0.1 (A redhat advanced server distribution) compared to other 64-bit architectures like amd64 and EM64T. There has been an increase of around 20% of the size. I verified the virtual address mappings in /proc//maps file and found that several .so files (other segments of same size) are getting mapped multiple times as follows. 2005c000-2007c000 r-xp 08:07 6521003 /usr/X11R6/lib/libXext.so.6.4 2007c000-2009 rw-p 0001 08:07 6521003 /usr/X11R6/lib/libXext.so.6.4 2009-20268000 r-xp 08:07 6520995 /usr/X11R6/lib/libX11.so.6.2 20268000-2027 ---p 001d8000 08:07 6520995 /usr/X11R6/lib/libX11.so.6.2 2027-20284000 rw-p 001d 08:07 6520995 /usr/X11R6/lib/libX11.so.6.2 20284000-2028c000 r-xp 08:07 6094863 /lib/libdl-2.2.4.so 2028c000-20294000 ---p 8000 08:07 6094863 /lib/libdl-2.2.4.so 20294000-2029c000 rw-p 08:07 6094863 /lib/libdl-2.2.4.so 2029c000-202b8000 r-xp 08:07 6094883 /lib/libpthread-0.9.so 202b8000-202bc000 ---p 0001c000 08:07 6094883 /lib/libpthread-0.9.so 202bc000-202d4000 rw-p 0001 08:07 6094883 /lib/libpthread-0.9.so 202d4000-20358000 r-xp 08:07 376886 /usr/lib/libncurses.so.5.2 20358000-20364000 ---p 00084000 08:07 376886 /usr/lib/libncurses.so.5.2 20364000-20374000 rw-p 0008 08:07 376886 /usr/lib/libncurses.so.5.2 20374000-20378000 rw-p 00:00 0 20378000-2040 r-xp 08:07 6094865 /lib/libm-2.2.4.so 2040-20408000 ---p 00088000 08:07 6094865 /lib/libm-2.2.4.so 20408000-20414000 rw-p 0008 08:07 6094865 /lib/libm-2.2.4.so 20414000-2065c000 r-xp 08:07 6094859 /lib/libc-2.2.4.so 2065c000-20664000 ---p 00248000 08:07 6094859 /lib/libc-2.2.4.so 20664000-20678000 rw-p 0024 08:07 6094859 /lib/libc-2.2.4.so --- example /lib/libc-2.2.4.so size 6094859got mapped 3 times with permissions 'r-xp' , '---p' and 'rw-p' from the bottom. I found the similar mappings for all the programs running on a IA-64 machine. Is this some special kernel kind of feature on IA-64 ?? Your kind inputs on this problem are greatly appreciated. Looking forward to hear from you. Thanks in advance, Vamsi kundeti - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multiple virtual address mapping for the same code on IA-64 linux kernel.
Hello All, Really thankful for your inputs! Itanium instruction set is not as compact as some other architectures, so the same program will typically require more bytes of code. I stopped the program on both amd64 machine and ia64 machine and grepped the values from /proc//status and found the following. Linux IPF--- VmSize: 126304 kB VmLck: 0 kB VmRSS: 6352 kB VmData:19696 kB VmStk:16 kB VmExe: 97760 kB VmLib: 3152 kB --AMD64- VmSize: 100432 kB VmLck: 0 kB VmRSS: 2828 kB VmData:24428 kB VmStk: 264 kB VmExe: 62848 kB VmLib: 3048 kB --- Seems like most of core size(VmSize) on ipf (126MB) is coming from the code size(VmExe) i.e 97MB. While the code size is just 62MB on amd64. Looks like IA-64 wastes a lot of VM due to big instruction sizes, so big instruction sizes will improve performance ? compared small instruction sizes? , but fetching big instructions surely takes time compared to small, this may be the reason why amd64 is the fasttest 64-bit process ? Thanks a lot! Vamsi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Forcing kernel to avoid vDSO mapping.
Hello All, Sorry to interrupt you. There seem to be some architecture specific problems using ptrace in the vDSO segment on IA32, ptrace and read fails from this segment with BAD ADDRESS. I was just wondering if there could be any why we can tell kernel not to map this vDSO for optimization of system call overhead. Your kind help and effort regarding this issue is greatly appreciated. Thanks a lot. Regards, Vamsi kundeti - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Forcing kernel to avoid vDSO mapping.
Hello All, Sorry to interrupt you. There seem to be some architecture specific problems using ptrace in the vDSO segment on IA32, ptrace and read fails from this segment with BAD ADDRESS. I was just wondering if there could be any why we can tell kernel not to map this vDSO for optimization of system call overhead. Your kind help and effort regarding this issue is greatly appreciated. Thanks a lot. Regards, Vamsi kundeti - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
Really appreciate that, is roland mcgrath listening? what's his email ID?
On 7/23/05, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
>
> On Fri, 22 Jul 2005, vamsi krishna wrote:
>
> > Hi,
> >
> >> It doesn't. The 32-bit machines never show 64 bit words in
> >> /proc/NN/maps. They don't "know" how.
> >>
> >> b7fd6000-b7fd7000 rw-p b7fd6000 00:00 0
> >> b7ff5000-b7ff6000 rw-p b7ff5000 00:00 0
> >> bffe1000-bfff6000 rw-p bffe1000 00:00 0 [stack]
> >> e000-f000 ---p 00:00 0 [vdso]
> >> 32 bits
> >
> > hello john can you tell me what is [vdso], does it have any content
> > related file descriptor table it seems that the if I dont save this
> > segment during checkpointing, the file open descriptors (i.e FILE *)
> > seems to have null after restoration.
> >
> > Sincerely appreciate your inputs.
> >
> > Cheers!
> > Vamsi
> >
>
> #include
>
> int main()
> {
> long *foo = (long *)0xe000;
> printf("%08x\n", foo[0]);
> printf("%08x\n", foo[1]);
> printf("%08x\n", foo[2]);
> printf("%08x\n", foo[3]);
> printf("%08x\n", foo[4]);
> printf("%s\n", (char *)foo);
>
> }
>
> Seems to be readable and starts with 'ELF'. It's something
> the the 'C' runtime may library use to make syscalls to the
> kernel. Older libraries used interrupt 0x80, newer ones
> may use this. Roland McGrath has made patches to this
> segment so maybe he knows.
>
>
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
> Warning : 98.36% of all statistics are fiction.
> .
> I apologize for the following. I tried to kill it with the above dot :
>
>
> The information transmitted in this message is confidential and may be
> privileged. Any review, retransmission, dissemination, or other use of this
> information by persons or entities other than the intended recipient is
> prohibited. If you are not the intended recipient, please notify Analogic
> Corporation immediately - by replying to this message or by sending an email
> to [EMAIL PROTECTED] - and destroy all copies of this information, including
> any attachments, without reading or disclosing them.
>
> Thank you.
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
Hi, > It doesn't. The 32-bit machines never show 64 bit words in > /proc/NN/maps. They don't "know" how. > > b7fd6000-b7fd7000 rw-p b7fd6000 00:00 0 > b7ff5000-b7ff6000 rw-p b7ff5000 00:00 0 > bffe1000-bfff6000 rw-p bffe1000 00:00 0 [stack] > e000-f000 ---p 00:00 0 [vdso] > 32 bits hello john can you tell me what is [vdso], does it have any content related file descriptor table it seems that the if I dont save this segment during checkpointing, the file open descriptors (i.e FILE *) seems to have null after restoration. Sincerely appreciate your inputs. Cheers! Vamsi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
Hello, > > The location of the vsyscall page is different on 32 and 64 bit > machines. So 0xe000 is NOT the address you are looking for while > dealing with the 64 bit machine. Rather 0xff60 is the > correct location (on x86-64). > Both my process's are 32-bit process's, its just one runs on 64-bit machine and other runs on 32-bit machine. The write from address 0xe to a file on a 32-bit machine fails, but does'nt fail on 64-bit machine (the process is still 32-bit although it runs on 64-bit). How can the virtual address of 0xff60 exist in a 32-bit process ? (May be I have not made myself clear in explaining the problem?? :-?) Best, Vamsi. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
Hello All, Sorry to interrupt you. I have been facing a wierd problem on same kernel version (2.6.5-7.97.smp) but running on different machines 32-bit and 64-bit (which can run 32-bit also). I found that every process running in this kernel version has a virtual address mapping in /proc//maps file as follows <--> e000-000 ---p 00:00 0 <--> You can find this vaddr mapping at end of maps file. on a 64-bit(uname --all == 'Linux host 2.6.5-7.97.smp #1 x86_64 x86_64 x86_64 GNU/Linux) machine which is running the same kernel, I try to write the contents of the virtual address on to file with (r = write(fd,0xe000,4096) ). The write on this machine is successful. But if I try to write the same segment on 32-bit machine (uname --all == Linux host 2.6.5-7.97-smp #1 i686 i686 i386 GNU/Linux). The write on this 32-bit machine fails with EFAULT(14), but if memcpy to a buffer from this virtual address seems to work fine i.e if I do 'memcpy(buf1,0xe000,4096)' it write perfectly the contents of this virtual address segment into the buf1. I had a hard time googling about this I could'nt find any information on why this happens. May be some mm hackers may share some of their thoughts. Really appreciate your inputs on this. Sincerely, Vamsi kundeti PS: BTW I'am running suse distribution and will glibc will have any effect on write behaviour ? (I though that since write is a syscall the issue might be with the kernel the thus skipping the glibc details) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
Hello All, Sorry to interrupt you. I have been facing a wierd problem on same kernel version (2.6.5-7.97.smp) but running on different machines 32-bit and 64-bit (which can run 32-bit also). I found that every process running in this kernel version has a virtual address mapping in /proc/pid/maps file as follows -- e000-000 ---p 00:00 0 -- You can find this vaddr mapping at end of maps file. on a 64-bit(uname --all == 'Linux host 2.6.5-7.97.smp #1 time stamp x86_64 x86_64 x86_64 GNU/Linux) machine which is running the same kernel, I try to write the contents of the virtual address on to file with (r = write(fd,0xe000,4096) ). The write on this machine is successful. But if I try to write the same segment on 32-bit machine (uname --all == Linux host 2.6.5-7.97-smp #1 timestamp i686 i686 i386 GNU/Linux). The write on this 32-bit machine fails with EFAULT(14), but if memcpy to a buffer from this virtual address seems to work fine i.e if I do 'memcpy(buf1,0xe000,4096)' it write perfectly the contents of this virtual address segment into the buf1. I had a hard time googling about this I could'nt find any information on why this happens. May be some mm hackers may share some of their thoughts. Really appreciate your inputs on this. Sincerely, Vamsi kundeti PS: BTW I'am running suse distribution and will glibc will have any effect on write behaviour ? (I though that since write is a syscall the issue might be with the kernel the thus skipping the glibc details) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
Hello, The location of the vsyscall page is different on 32 and 64 bit machines. So 0xe000 is NOT the address you are looking for while dealing with the 64 bit machine. Rather 0xff60 is the correct location (on x86-64). Both my process's are 32-bit process's, its just one runs on 64-bit machine and other runs on 32-bit machine. The write from address 0xe to a file on a 32-bit machine fails, but does'nt fail on 64-bit machine (the process is still 32-bit although it runs on 64-bit). How can the virtual address of 0xff60 exist in a 32-bit process ? (May be I have not made myself clear in explaining the problem?? :-?) Best, Vamsi. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
Hi, It doesn't. The 32-bit machines never show 64 bit words in /proc/NN/maps. They don't know how. b7fd6000-b7fd7000 rw-p b7fd6000 00:00 0 b7ff5000-b7ff6000 rw-p b7ff5000 00:00 0 bffe1000-bfff6000 rw-p bffe1000 00:00 0 [stack] e000-f000 ---p 00:00 0 [vdso] 32 bits hello john can you tell me what is [vdso], does it have any content related file descriptor table it seems that the if I dont save this segment during checkpointing, the file open descriptors (i.e FILE *) seems to have null after restoration. Sincerely appreciate your inputs. Cheers! Vamsi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Whats in this vaddr segment 0xffffe000-0xfffff000 ---p ?
Really appreciate that, is roland mcgrath listening? what's his email ID?
On 7/23/05, linux-os (Dick Johnson) [EMAIL PROTECTED] wrote:
On Fri, 22 Jul 2005, vamsi krishna wrote:
Hi,
It doesn't. The 32-bit machines never show 64 bit words in
/proc/NN/maps. They don't know how.
b7fd6000-b7fd7000 rw-p b7fd6000 00:00 0
b7ff5000-b7ff6000 rw-p b7ff5000 00:00 0
bffe1000-bfff6000 rw-p bffe1000 00:00 0 [stack]
e000-f000 ---p 00:00 0 [vdso]
32 bits
hello john can you tell me what is [vdso], does it have any content
related file descriptor table it seems that the if I dont save this
segment during checkpointing, the file open descriptors (i.e FILE *)
seems to have null after restoration.
Sincerely appreciate your inputs.
Cheers!
Vamsi
#include stdio.h
int main()
{
long *foo = (long *)0xe000;
printf(%08x\n, foo[0]);
printf(%08x\n, foo[1]);
printf(%08x\n, foo[2]);
printf(%08x\n, foo[3]);
printf(%08x\n, foo[4]);
printf(%s\n, (char *)foo);
}
Seems to be readable and starts with 'ELF'. It's something
the the 'C' runtime may library use to make syscalls to the
kernel. Older libraries used interrupt 0x80, newer ones
may use this. Roland McGrath has made patches to this
segment so maybe he knows.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :
The information transmitted in this message is confidential and may be
privileged. Any review, retransmission, dissemination, or other use of this
information by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify Analogic
Corporation immediately - by replying to this message or by sending an email
to [EMAIL PROTECTED] - and destroy all copies of this information, including
any attachments, without reading or disclosing them.
Thank you.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Avoiding BIGMEM support programatically.
Hello All, I have a program working fine on a 2.6.xx-smp kernel, and the program crashes on the same version kernel with bigmem i.e (2.6.xxx-bigmem). I also found that for a same executable on bigmem kernel the virtual address's of '&_start' and '&_etext', seem to vary in every new run. Is there any way I can avoid the kernel's bigmem virtual address mapping programatically? and still run the program on a bigmem kernel? Really appreciate your help in this context. Best Regards, Vamsi Kundeti. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Avoiding BIGMEM support programatically.
Hello All, I have a program working fine on a 2.6.xx-smp kernel, and the program crashes on the same version kernel with bigmem i.e (2.6.xxx-bigmem). I also found that for a same executable on bigmem kernel the virtual address's of '_start' and '_etext', seem to vary in every new run. Is there any way I can avoid the kernel's bigmem virtual address mapping programatically? and still run the program on a bigmem kernel? Really appreciate your help in this context. Best Regards, Vamsi Kundeti. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory.
Hello Alan, mm-hackers, I have been working this idea of increasing virtual address space of a process with the help of secondary memory. At first this may seem like the same virtual memory concept but its not the case. Imagine all the virtual address the compiler generates while creating the binary as relocatable offsets on the disk, and the application specific runtime mmaps and munmaps these dynamically. I was searching a lot about work on this, and found your reply where you say that we can increase the virtual address space by mmaping and munmaping programatically ourself. So is the bigmem kernel implement this? may be you can give me some insight into this. Some inputs on this would be highly appreciated. Sincerely, Vamsi kundeti. PS: Please refer this kernel mailing list email. <--SNIP---> Re: BIGMEM kernel question From: Alan Cox ([EMAIL PROTECTED]) Date: Fri Jul 06 2001 - 16:46:16 EST > Ahh. That makes sense. So how can I change the chunk size from 64k to > something higher (I assume I could set it to 128k to effectively double > that 3GB to 6GB)? I think you misunderstand. If you want more than 3Gb you will have to map and unmap stuff yourself. You only have 3Gb of per process address space due to x86 weaknesses (lack of seperate kernel/user spaces without tlb flush overhead nightmares) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ * Next message: Donald Becker: "Re: why this 1ms delay in mdio_read? (cont'd from "are ioctl calls supposed to take this long?")" * Previous message: Rik van Riel: "Re: BIGMEM kernel question" * In reply to: Eric Anderson: "Re: BIGMEM kernel question" * Next in thread: Brian Gerst: "Re: BIGMEM kernel question" * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] <--SNIP-> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Increasing virtual address space of a process, by treating virtual address's as offsets in secondary memory.
Hello Alan, mm-hackers, I have been working this idea of increasing virtual address space of a process with the help of secondary memory. At first this may seem like the same virtual memory concept but its not the case. Imagine all the virtual address the compiler generates while creating the binary as relocatable offsets on the disk, and the application specific runtime mmaps and munmaps these dynamically. I was searching a lot about work on this, and found your reply where you say that we can increase the virtual address space by mmaping and munmaping programatically ourself. So is the bigmem kernel implement this? may be you can give me some insight into this. Some inputs on this would be highly appreciated. Sincerely, Vamsi kundeti. PS: Please refer this kernel mailing list email. --SNIP--- Re: BIGMEM kernel question From: Alan Cox ([EMAIL PROTECTED]) Date: Fri Jul 06 2001 - 16:46:16 EST Ahh. That makes sense. So how can I change the chunk size from 64k to something higher (I assume I could set it to 128k to effectively double that 3GB to 6GB)? I think you misunderstand. If you want more than 3Gb you will have to map and unmap stuff yourself. You only have 3Gb of per process address space due to x86 weaknesses (lack of seperate kernel/user spaces without tlb flush overhead nightmares) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ * Next message: Donald Becker: Re: why this 1ms delay in mdio_read? (cont'd from are ioctl calls supposed to take this long?) * Previous message: Rik van Riel: Re: BIGMEM kernel question * In reply to: Eric Anderson: Re: BIGMEM kernel question * Next in thread: Brian Gerst: Re: BIGMEM kernel question * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] --SNIP- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
