Re: factor is too fast
On Tue, 21 Apr 2009, Toralf F?rster wrote: For a long time I used the command factor to test my system WRT the cpu ondemand governor of the linux kernel, eg for issues like this : http://bugzilla.kernel.org/show_bug.cgi?id=12385 However switching from coreutils-6.10 to 7.1 (stable Gentoo Linux) now the factor command is too fast: it takes only 0.003 sec instead of 5.5 sec for the same prime number. That's probably due to this entry from NEWS: * Noteworthy changes in release 7.0 (2008-10-05) [beta] If the GNU MP library is available at configure time, factor and expr support arbitrarily large numbers. Pollard's rho algorithm is used to factor large numbers. Therefore I'm wondering whether you have a hint for me which number I could use nowadays ? If the goal is simply drive the CPU usage to 100% for 5 seconds, this would work: $ timeout 5 factor 20158916322613169725842061629370496430 Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
factor is too fast
For a long time I used the command factor to test my system WRT the cpu ondemand governor of the linux kernel, eg for issues like this : http://bugzilla.kernel.org/show_bug.cgi?id=12385 However switching from coreutils-6.10 to 7.1 (stable Gentoo Linux) now the factor command is too fast: it takes only 0.003 sec instead of 5.5 sec for the same prime number. Therefore I'm wondering whether you have a hint for me which number I could use nowadays ? :-) Thx -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
7.2 on Solaris 10 with Zones
Just built 7.2 on Solaris 10/SPARC and src/df doesn't seem to like zones: $ src/df ... src/df: `/var/zones/poog/root/.SUNWnative/lib': Permission denied src/df: `/var/zones/poog/root/.SUNWnative/platform': Permission denied src/df: `/var/zones/poog/root/.SUNWnative/usr': Permission denied src/df: `/var/zones/poog/root/dev': Permission denied src/df: `/var/zones/poog/root/opt/build': Permission denied src/df: `/var/zones/poog/root/proc': Permission denied src/df: `/var/zones/poog/root/etc/mnttab': Permission denied src/df: `/var/zones/poog/root/etc/svc/volatile': Permission denied src/df: `/var/zones/poog/root/dev/ksyms': Permission denied src/df: `/var/zones/poog/root/dev/fd': Permission denied ... When run as root, I get: $ src/df ... src/df: `/var/zones/poog/root/opt/dist': Not owner src/df: `/var/zones/poog/root/opt/tww': Not owner src/df: `/var/zones/poog/root/home': Not owner src/df: `/var/zones/poog/root/opt/src': Not owner src/df: `/var/zones/poog/root/opt/src/latest': Not owner ... $ grep /var/zones/poog/root/.SUNWnative/lib /etc/mnttab /lib/var/zones/poog/root/.SUNWnative/liblofs ro,nodevices,dev=80 1240195097 $ grep /var/zones/poog/root/opt/build /etc/mnttab /dev/dsk/c1t1d0s4 /var/zones/poog/root/opt/build ufs rw,intr,largefiles,logging,xattr,onerror=panic,dev=8c 1240195097 $ grep /var/zones/gax/root/home /etc/mnttab sanji:/home /var/zones/gax/root/homenfs rw,nosuid,hard,intr,bg,zone=gax,dev=5a40643 1240271940 -- albert chin (ch...@thewrittenword.com) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: chroot documentation
On Tue, Apr 21, 2009 at 6:35 PM, Stefano Carucci stecaru...@hotmail.com wrote: Hello all! Can anyone suggest to me a detailed guide about the chroot implementation ? The implementation in coreutils or the one in your kernel?The implementation of chroot(1) in coreurils looks pretty much like this: chroot(the-specified-directory) chdir(/) execvp(your_program_name, argument_list); If that looks very short, well, it is. The coreutils implementation of chroot is only 115 lines, including header comment, option parsing, and error handling. What I am interested in is how it creates the new root, It doesn't. The directory to which you chroot must already exist. what the computational effort is Minimal. # /usr/bin/time -v chroot /var/vserver/chroot/debian/etch/x86/a /bin/true Command being timed: chroot /var/vserver/chroot/debian/etch/x86/a /bin/true User time (seconds): 0.00 System time (seconds): 0.00 Percent of CPU this job got: 266% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.00 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 0 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 293 Voluntary context switches: 3 Involuntary context switches: 0 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 and what it does at a low-level; not just a synopsis. If you want to know what it does at a low level, you are better off enquiring into the properties of the implementation, not the command-line tool that thinly wraps the system call. You might want to download the sources for Linux or for some *BSD kernel or some such thing, in order to understand how the system call works. But this mailing list isn't really the right place to enquire about the internals of those kernels, since we don't write them. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Arbitrary hunk sizes for patch
Hi list, When modifying patch files, i'm getting a bit sick of counting lines just so I can modify hunk sizes to correctly apply a patch. Then I noticed at the bottom of the man page for patch: Paul Eggert removed patchs arbitrary limits Has that statement got anything to do with arbitrary hunk sizes? If so, could this be reinstated but only turned on with a flag e.g. -a or --abitrary-size Alfie ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Arbitrary hunk sizes for patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Alfie on 4/21/2009 6:55 PM: Hi list, When modifying patch files, i'm getting a bit sick of counting lines just so I can modify hunk sizes to correctly apply a patch. Wrong list. You want to ask this on bug-patch (the address listed in 'patch --help'). However, 'git apply', which is very similar to patch, has already implemented this concept, in its --recount option, so it seems like a reasonable request. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknupmsACgkQ84KuGfSFAYD21QCeMElnu4oQ4gM314l6haKH9Iba w3kAn0thWNqisOrD9cMHO/BnG4xspQbs =O5st -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
