From unknown Sun Jun 22 04:35:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12738: 'sort' wastes cpu-cycles of all available cpus Resent-From: "Schwidom, Frank" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 26 Oct 2012 07:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 12738 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 12738@debbugs.gnu.org X-Debbugs-Original-To: "bug-coreutils@gnu.org" Received: via spool by submit@debbugs.gnu.org id=B.135123754029126 (code B ref -1); Fri, 26 Oct 2012 07:46:02 +0000 Received: (at submit) by debbugs.gnu.org; 26 Oct 2012 07:45:40 +0000 Received: from localhost ([127.0.0.1]:34142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TRebq-0007Zi-Mj for submit@debbugs.gnu.org; Fri, 26 Oct 2012 03:45:39 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60324) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TReSQ-0007M2-SX for submit@debbugs.gnu.org; Fri, 26 Oct 2012 03:35:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TReQL-0001Dj-JN for submit@debbugs.gnu.org; Fri, 26 Oct 2012 03:33:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, FILL_THIS_FORM_SHORT, HTML_MESSAGE, RCVD_IN_DNSWL_HI, RECEIVED_FROM_WINDOWS_HOST autolearn=ham version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:35893) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TReQL-0001DR-Ga for submit@debbugs.gnu.org; Fri, 26 Oct 2012 03:33:45 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TReQK-00033s-31 for bug-coreutils@gnu.org; Fri, 26 Oct 2012 03:33:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TReQD-00018m-S9 for bug-coreutils@gnu.org; Fri, 26 Oct 2012 03:33:43 -0400 Received: from edge1.hs-lausitz.de ([193.174.73.196]:45947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TReQD-00016j-DI for bug-coreutils@gnu.org; Fri, 26 Oct 2012 03:33:37 -0400 Received: from Egon12.HS-Lausitz.int (193.174.72.20) by edge1.hs-lausitz.de (193.174.73.196) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 26 Oct 2012 09:13:04 +0200 Received: from egon11.HS-Lausitz.int ([fe80::3871:9378:7540:40b6]) by Egon12.HS-Lausitz.int ([193.174.72.20]) with mapi; Fri, 26 Oct 2012 09:12:49 +0200 From: "Schwidom, Frank" Date: Fri, 26 Oct 2012 09:12:40 +0200 Thread-Topic: 'sort' wastes cpu-cycles of all available cpus Thread-Index: Ac2zSUlw+ri8ZlW0TgaefXAa5u6gAA== Message-ID: <49D97E36F5CBCC418DA979588775576303BABBE730E2@EGON11.HS-Lausitz.int> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_49D97E36F5CBCC418DA979588775576303BABBE730E2EGON11HSLau_" MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Windows XP/2000 (RFC1323+, w+, tstamp-) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Mailman-Approved-At: Fri, 26 Oct 2012 03:45:37 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) --_000_49D97E36F5CBCC418DA979588775576303BABBE730E2EGON11HSLau_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In some situations sort wastes cpu-cycles of all available cpus. Hi, I refer to 'sort' of the following Version: $ sort --version sort (GNU coreutils) 8.7 Packaged by Gentoo (8.7 (p1)) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Mike Haertel and Paul Eggert. on the system: $ uname -a Linux CUDA 2.6.38-gentoo-r6 #12 SMP Fri Sep 14 12:59:07 CEST 2012 x86_64 In= tel(R) Xeon(R) CPU E5645 @ 2.40GHz GenuineIntel GNU/Linux The problem causes, if the input of sort is very long but the output is not= taken. if i call: # seq 1 10000000 | sort -R | wc -l 10000000 then sort itself uses only circa 10 cpus: top: 8316 root 20 0 359m 185m 676 S 1009 1.5 4:08.18 sort or ca. 4 cpus in this case: # seq 1 10000000 | sort -n | wc -l 10000000 top: 8782 root 20 0 295m 185m 672 S 382 1.5 0:25.18 sort while sort is running, this behaviour is ok. it would be ok too, if it would use all cpus. but, if i use: # seq 1 1000000 | sort -n | less and while im not scrolling to the bottom in 'less' sort uses all cpus top: 9421 root 20 0 447m 109m 660 R 2295 0.9 3:12.72 sort in this case, sort is already done sorting (it took and sorted the whole input and 'less' displays values). but it takes a lot of cpu-cycles on all cpus. if i scroll to the bottom, 'less' takes all values of the sort output and sort will end; this is ok. Regards Mit freundlichen Gr=FC=DFen Frank Schwidom Dipl.-Inf. (FH) Hochschule Lausitz (FH) Fertigungstechnik/ Tribologie Prof. Dr.-Ing. R. Winkelmann Gro=DFenhainer Str. 57 01968 Senftenberg Fone : +49 (0) 3573 85 435 Fax: +49 (0) 3573 85 426 Email: Frank.Schwidom@HS-Lausitz.de Homepage: http://www2.fh-lausitz.de/fhl/mb/labor/tribologie/Index.html --_000_49D97E36F5CBCC418DA979588775576303BABBE730E2EGON11HSLau_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

In some situations sort wastes cpu-= cycles of all available cpus.

 

Hi,

 

I refer to 'sort' of the following = Version:

 

$ sort --version

sort (GNU coreutils) 8.7

Packaged by Gentoo (8.7 (p1))<= /o:p>

Copyright (C) 2010 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 o= r later <http://gnu.org/licenses/gpl.html>.

This is free software: you are free= to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Written by Mike Haertel and Paul Eg= gert.

 

on the system:

 

$ uname -a

Linux CUDA 2.6.38-gentoo-r6 #12 SMP= Fri Sep 14 12:59:07 CEST 2012 x86_64 Intel(R) Xeon(R) CPU E5645 @ 2.40GHz GenuineIn= tel GNU/Linux

 

The problem causes, if the input of= sort is very long but the output is not taken.

 

if i call:

 

# seq 1 10000000 | sort -R | wc -l<= o:p>

10000000

 

then sort itself uses only circa 10= cpus:

 

top:

=A08316 root=A0=A0=A0=A0=A0 20=A0= =A0 0=A0 359m 185m=A0 676 S 1009=A0 1.5=A0=A0 4:08.18 sort=A0

 

or ca. 4 cpus in this case:

 

# seq 1 10000000 | sort -n | wc -l<= o:p>

10000000

 

top:

=A08782 root=A0=A0=A0=A0=A0 20=A0= =A0 0=A0 295m 185m=A0 672 S=A0 382=A0 1.5=A0=A0 0:25.18 sort

=A0

while sort is running, this behavio= ur is ok. it would be ok too, if

it would use all cpus.

 

but, if i use:

 

# seq 1 1000000 | sort -n | less

 

and while im not scrolling to the b= ottom in 'less'

sort uses all cpus

 

top:

=A09421 root=A0=A0=A0=A0=A0 20=A0= =A0 0=A0 447m 109m=A0 660 R 2295=A0 0.9=A0=A0 3:12.72 sort=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

 

in this case, sort is already done = sorting (it took and sorted

the whole input and 'less' displays= values).

but it takes a lot of cpu-cycles on= all cpus.

 

if i scroll to the bottom, 'less' t= akes all values of the sort output

and sort will end; this is ok.=

 

Regards

 

 

Mit freundlichen Gr=FC=DFen

 

Frank Schwidom

Dipl.-Inf. (FH)

 

Hochschule Lausitz (FH)

Fertigungstechnik/ Tribologie

Prof. Dr.-Ing. R. Winkelmann

Gro=DFenhainer Str. 57

01968 Senftenberg

 

Fone :       +49 (0) 3573 85 435<= o:p>

Fax:          +49 = (0) 3573 85 426

Email:=A0=A0=A0=A0=A0=A0 Frank.Schwidom@HS-Lausitz.de

Homepage:  http://www2.fh-lausitz.de/fhl/mb/labor/tr= ibologie/Index.html

 

--_000_49D97E36F5CBCC418DA979588775576303BABBE730E2EGON11HSLau_-- From unknown Sun Jun 22 04:35:26 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: "Schwidom, Frank" Subject: bug#12738: closed (Re: bug#12738: 'sort' wastes cpu-cycles of all available cpus) Message-ID: References: <87bofp4liw.fsf@meyering.net> <49D97E36F5CBCC418DA979588775576303BABBE730E2@EGON11.HS-Lausitz.int> X-Gnu-PR-Message: they-closed 12738 X-Gnu-PR-Package: coreutils Reply-To: 12738@debbugs.gnu.org Date: Fri, 26 Oct 2012 09:45:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1351244702-6989-1" This is a multi-part message in MIME format... ------------=_1351244702-6989-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #12738: 'sort' wastes cpu-cycles of all available cpus which was filed against the coreutils package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 12738@debbugs.gnu.org. --=20 12738: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D12738 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1351244702-6989-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 12738-done) by debbugs.gnu.org; 26 Oct 2012 09:44:42 +0000 Received: from localhost ([127.0.0.1]:34230 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TRgT4-0001o7-B0 for submit@debbugs.gnu.org; Fri, 26 Oct 2012 05:44:42 -0400 Received: from mx.meyering.net ([88.168.87.75]:37206) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TRgT2-0001nz-H1 for 12738-done@debbugs.gnu.org; Fri, 26 Oct 2012 05:44:41 -0400 Received: from rho (rho.meyering.net [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id A6BD66012B; Fri, 26 Oct 2012 11:42:31 +0200 (CEST) From: Jim Meyering To: "Schwidom\, Frank" Subject: Re: bug#12738: 'sort' wastes cpu-cycles of all available cpus In-Reply-To: <49D97E36F5CBCC418DA979588775576303BABBE730E2@EGON11.HS-Lausitz.int> (Frank Schwidom's message of "Fri, 26 Oct 2012 09:12:40 +0200") References: <49D97E36F5CBCC418DA979588775576303BABBE730E2@EGON11.HS-Lausitz.int> Date: Fri, 26 Oct 2012 11:42:31 +0200 Message-ID: <87bofp4liw.fsf@meyering.net> Lines: 38 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.1 (/) X-Debbugs-Envelope-To: 12738-done Cc: 12738-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.1 (/) Schwidom, Frank wrote: > In some situations sort wastes cpu-cycles of all available cpus. > > $ sort --version > sort (GNU coreutils) 8.7 ... > but, if i use: > > # seq 1 1000000 | sort -n | less > > and while im not scrolling to the bottom in 'less' > sort uses all cpus > > top: > 9421 root 20 0 447m 109m 660 R 2295 0.9 3:12.72 sort > > in this case, sort is already done sorting (it took and sorted > the whole input and 'less' displays values). > but it takes a lot of cpu-cycles on all cpus. > > if i scroll to the bottom, 'less' takes all values of the sort output > and sort will end; this is ok. Thank you for the report. However, your version of sort is quite old and that bug was fixed almost two years ago: (from "NEWS") * Noteworthy changes in release 8.8 (2010-12-22) [stable] ** Bug fixes sort with at least two threads and with blocked output would busy-loop (spinlock) all threads, often using 100% of available CPU cycles to do no work. I.e., "sort < big-file | less" could waste a lot of power. [bug introduced in coreutils-8.6] The latest release is coreutils-8.20. ------------=_1351244702-6989-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 26 Oct 2012 07:45:40 +0000 Received: from localhost ([127.0.0.1]:34142 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TRebq-0007Zi-Mj for submit@debbugs.gnu.org; Fri, 26 Oct 2012 03:45:39 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60324) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TReSQ-0007M2-SX for submit@debbugs.gnu.org; Fri, 26 Oct 2012 03:35:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TReQL-0001Dj-JN for submit@debbugs.gnu.org; Fri, 26 Oct 2012 03:33:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, FILL_THIS_FORM_SHORT, HTML_MESSAGE, RCVD_IN_DNSWL_HI, RECEIVED_FROM_WINDOWS_HOST autolearn=ham version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:35893) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TReQL-0001DR-Ga for submit@debbugs.gnu.org; Fri, 26 Oct 2012 03:33:45 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44031) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TReQK-00033s-31 for bug-coreutils@gnu.org; Fri, 26 Oct 2012 03:33:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TReQD-00018m-S9 for bug-coreutils@gnu.org; Fri, 26 Oct 2012 03:33:43 -0400 Received: from edge1.hs-lausitz.de ([193.174.73.196]:45947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TReQD-00016j-DI for bug-coreutils@gnu.org; Fri, 26 Oct 2012 03:33:37 -0400 Received: from Egon12.HS-Lausitz.int (193.174.72.20) by edge1.hs-lausitz.de (193.174.73.196) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 26 Oct 2012 09:13:04 +0200 Received: from egon11.HS-Lausitz.int ([fe80::3871:9378:7540:40b6]) by Egon12.HS-Lausitz.int ([193.174.72.20]) with mapi; Fri, 26 Oct 2012 09:12:49 +0200 From: "Schwidom, Frank" To: "bug-coreutils@gnu.org" Date: Fri, 26 Oct 2012 09:12:40 +0200 Subject: 'sort' wastes cpu-cycles of all available cpus Thread-Topic: 'sort' wastes cpu-cycles of all available cpus Thread-Index: Ac2zSUlw+ri8ZlW0TgaefXAa5u6gAA== Message-ID: <49D97E36F5CBCC418DA979588775576303BABBE730E2@EGON11.HS-Lausitz.int> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_49D97E36F5CBCC418DA979588775576303BABBE730E2EGON11HSLau_" MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Windows XP/2000 (RFC1323+, w+, tstamp-) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 26 Oct 2012 03:45:37 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) --_000_49D97E36F5CBCC418DA979588775576303BABBE730E2EGON11HSLau_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In some situations sort wastes cpu-cycles of all available cpus. Hi, I refer to 'sort' of the following Version: $ sort --version sort (GNU coreutils) 8.7 Packaged by Gentoo (8.7 (p1)) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Mike Haertel and Paul Eggert. on the system: $ uname -a Linux CUDA 2.6.38-gentoo-r6 #12 SMP Fri Sep 14 12:59:07 CEST 2012 x86_64 In= tel(R) Xeon(R) CPU E5645 @ 2.40GHz GenuineIntel GNU/Linux The problem causes, if the input of sort is very long but the output is not= taken. if i call: # seq 1 10000000 | sort -R | wc -l 10000000 then sort itself uses only circa 10 cpus: top: 8316 root 20 0 359m 185m 676 S 1009 1.5 4:08.18 sort or ca. 4 cpus in this case: # seq 1 10000000 | sort -n | wc -l 10000000 top: 8782 root 20 0 295m 185m 672 S 382 1.5 0:25.18 sort while sort is running, this behaviour is ok. it would be ok too, if it would use all cpus. but, if i use: # seq 1 1000000 | sort -n | less and while im not scrolling to the bottom in 'less' sort uses all cpus top: 9421 root 20 0 447m 109m 660 R 2295 0.9 3:12.72 sort in this case, sort is already done sorting (it took and sorted the whole input and 'less' displays values). but it takes a lot of cpu-cycles on all cpus. if i scroll to the bottom, 'less' takes all values of the sort output and sort will end; this is ok. Regards Mit freundlichen Gr=FC=DFen Frank Schwidom Dipl.-Inf. (FH) Hochschule Lausitz (FH) Fertigungstechnik/ Tribologie Prof. Dr.-Ing. R. Winkelmann Gro=DFenhainer Str. 57 01968 Senftenberg Fone : +49 (0) 3573 85 435 Fax: +49 (0) 3573 85 426 Email: Frank.Schwidom@HS-Lausitz.de Homepage: http://www2.fh-lausitz.de/fhl/mb/labor/tribologie/Index.html --_000_49D97E36F5CBCC418DA979588775576303BABBE730E2EGON11HSLau_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

In some situations sort wastes cpu-= cycles of all available cpus.

 

Hi,

 

I refer to 'sort' of the following = Version:

 

$ sort --version

sort (GNU coreutils) 8.7

Packaged by Gentoo (8.7 (p1))<= /o:p>

Copyright (C) 2010 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 o= r later <http://gnu.org/licenses/gpl.html>.

This is free software: you are free= to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

 

Written by Mike Haertel and Paul Eg= gert.

 

on the system:

 

$ uname -a

Linux CUDA 2.6.38-gentoo-r6 #12 SMP= Fri Sep 14 12:59:07 CEST 2012 x86_64 Intel(R) Xeon(R) CPU E5645 @ 2.40GHz GenuineIn= tel GNU/Linux

 

The problem causes, if the input of= sort is very long but the output is not taken.

 

if i call:

 

# seq 1 10000000 | sort -R | wc -l<= o:p>

10000000

 

then sort itself uses only circa 10= cpus:

 

top:

=A08316 root=A0=A0=A0=A0=A0 20=A0= =A0 0=A0 359m 185m=A0 676 S 1009=A0 1.5=A0=A0 4:08.18 sort=A0

 

or ca. 4 cpus in this case:

 

# seq 1 10000000 | sort -n | wc -l<= o:p>

10000000

 

top:

=A08782 root=A0=A0=A0=A0=A0 20=A0= =A0 0=A0 295m 185m=A0 672 S=A0 382=A0 1.5=A0=A0 0:25.18 sort

=A0

while sort is running, this behavio= ur is ok. it would be ok too, if

it would use all cpus.

 

but, if i use:

 

# seq 1 1000000 | sort -n | less

 

and while im not scrolling to the b= ottom in 'less'

sort uses all cpus

 

top:

=A09421 root=A0=A0=A0=A0=A0 20=A0= =A0 0=A0 447m 109m=A0 660 R 2295=A0 0.9=A0=A0 3:12.72 sort=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

 

in this case, sort is already done = sorting (it took and sorted

the whole input and 'less' displays= values).

but it takes a lot of cpu-cycles on= all cpus.

 

if i scroll to the bottom, 'less' t= akes all values of the sort output

and sort will end; this is ok.=

 

Regards

 

 

Mit freundlichen Gr=FC=DFen

 

Frank Schwidom

Dipl.-Inf. (FH)

 

Hochschule Lausitz (FH)

Fertigungstechnik/ Tribologie

Prof. Dr.-Ing. R. Winkelmann

Gro=DFenhainer Str. 57

01968 Senftenberg

 

Fone :       +49 (0) 3573 85 435<= o:p>

Fax:          +49 = (0) 3573 85 426

Email:=A0=A0=A0=A0=A0=A0 Frank.Schwidom@HS-Lausitz.de

Homepage:  http://www2.fh-lausitz.de/fhl/mb/labor/tr= ibologie/Index.html

 

--_000_49D97E36F5CBCC418DA979588775576303BABBE730E2EGON11HSLau_-- ------------=_1351244702-6989-1-- From unknown Sun Jun 22 04:35:26 2025 X-Loop: help-debbugs@gnu.org Subject: bug#12738: 'sort' wastes cpu-cycles of all available cpus Resent-From: Mike Frysinger Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-coreutils@gnu.org Resent-Date: Fri, 26 Oct 2012 21:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12738 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 12738@debbugs.gnu.org Cc: 12738-done@debbugs.gnu.org, "Schwidom, Frank" , Jim Meyering X-Debbugs-Original-To: bug-coreutils@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.135128702422648 (code B ref -1); Fri, 26 Oct 2012 21:31:02 +0000 Received: (at submit) by debbugs.gnu.org; 26 Oct 2012 21:30:24 +0000 Received: from localhost ([127.0.0.1]:35240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TRrU0-0005tF-9h for submit@debbugs.gnu.org; Fri, 26 Oct 2012 17:30:24 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60091) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TRrTw-0005t1-3g for submit@debbugs.gnu.org; Fri, 26 Oct 2012 17:30:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRrRo-00080Y-1T for submit@debbugs.gnu.org; Fri, 26 Oct 2012 17:28:08 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:48309) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRrRn-00080U-U8 for submit@debbugs.gnu.org; Fri, 26 Oct 2012 17:28:07 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRrRm-0005lh-Ku for bug-coreutils@gnu.org; Fri, 26 Oct 2012 17:28:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRrRl-0007za-HK for bug-coreutils@gnu.org; Fri, 26 Oct 2012 17:28:06 -0400 Received: from smtp.gentoo.org ([140.211.166.183]:51943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRrRl-0007zW-BX for bug-coreutils@gnu.org; Fri, 26 Oct 2012 17:28:05 -0400 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id C7BC133D931; Fri, 26 Oct 2012 21:28:04 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org Date: Fri, 26 Oct 2012 17:28:04 -0400 User-Agent: KMail/1.13.7 (Linux/3.6.3; KDE/4.6.5; x86_64; ; ) References: <49D97E36F5CBCC418DA979588775576303BABBE730E2@EGON11.HS-Lausitz.int> <87bofp4liw.fsf@meyering.net> In-Reply-To: <87bofp4liw.fsf@meyering.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4092085.eLlQPomY2E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201210261728.05405.vapier@gentoo.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -3.4 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.4 (---) --nextPart4092085.eLlQPomY2E Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Friday 26 October 2012 05:42:31 Jim Meyering wrote: > Schwidom, Frank wrote: > > In some situations sort wastes cpu-cycles of all available cpus. > >=20 > > $ sort --version > > sort (GNU coreutils) 8.7 > > Packaged by Gentoo (8.7 (p1)) >=20 > However, your version of sort is quite old and > that bug was fixed almost two years ago: > (from "NEWS") >=20 > * Noteworthy changes in release 8.8 (2010-12-22) [stable] >=20 > ** Bug fixes >=20 > sort with at least two threads and with blocked output would > busy-loop (spinlock) all threads, often using 100% of available CPU cycles > to do no work. I.e., "sort < big-file | less" could waste a lot of power. > [bug introduced in coreutils-8.6] >=20 > The latest release is coreutils-8.20. and Gentoo has stabilized newer versions in the interim with 8.16 going sta= ble=20 most recently in Aug 2012. =2Dmike --nextPart4092085.eLlQPomY2E Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJQiwBlAAoJEEFjO5/oN/WB8aQP/AxFYl+hzBKSvJMJtl0zLzwh WisPP4ix0pmKA87FZPGY03KXqxcGfseufk9r0vPTIKs+vw5B5T6dEQirs4/NCn8o Br3eH3KrSsmZRiM3GHQNgmrzzBdy98IX8nF4j5+87GEd6b+5wPfvg6ktLBHNGOG2 h1rzaa7E+OHZwqU+XUDWmJXqCWMaVV4FbkbuxafY0UtMXlOPqg/srvCbVyBsKngr ZbwWau1cKGk30sk+K0FyFjWD/cIvgTak7lTlL1j8FEVXuuz8UcKvRL2RwY00V3mH LDp3dLU0oc51tdgvu6uKgOkG11rTNfI7PIOoD3XBrcj3QSyIJc3UdgPg3pD/PmNH d4subv1Id6QgRoAmVthF2qs0iKxUWudUq6LEUPEsS7tkvFl3sobkOOxZBs2bPIL4 oh9kS83w3tIPQ+xthOwZ9RfspZ5w8P/yvCAC3nwJibbPehqvnXBgb++y91C4dE6X x+DUd1ESQ9i0yZmBEOVt1BXTaUEp8UL/Zjh85XKdoB96C1CmULEfyNzb9r+yKGcl 6Xziy1QVeZh6BrzR2/KtDhmYmh95aFxHnUV73dxQUBl7sVCiCG8uT2dKV6f5dD52 5TODB9kr8O4a1WhdDL1Cgs2QYRGHpje0gG7Kfv+qvx8XORkLKKqmUrWLejOF4Jlo E2E0t8SPOC03y9wTHujE =1jiT -----END PGP SIGNATURE----- --nextPart4092085.eLlQPomY2E--