LinuxLists.cc - linux-next: Tree for December 27

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

On Mon, Dec 27, 2010 at 7:04 AM, Stephen Rothwell <[email protected]> wrote:
> Hi all,
>
> [The mirroring on kernel.org is running slowly]
>
> Changes since 20101221:
>

Can you try to upload/push via IPADDR?

$ host git.kernel.org
git.kernel.org is an alias for git.geo.kernel.org.
git.geo.kernel.org is an alias for git.eu.kernel.org.
git.eu.kernel.org has address 199.6.1.166
git.eu.kernel.org has address 130.239.17.7

Being in EU, I get nearly maximum of my DSL-6000 download-rate:

$ git clone git://130.239.17.7/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git
Cloning into linux-npiggin...
remote: Counting objects: 1812908, done.
remote: Compressing objects: 100% (279491/279491), done.
Receiving objects: 13% (252336/1812908), 111.50 MiB | 689 KiB/s

> The sound tree gained a build failure, so I used the version that would
> have been in next-20101223.
>

I thought there was no "next-20101223" :-).

Can you please upload the patch-diff to
<http://www.kernel.org/pub/linux/kernel/v2.6/next/>?
Thanks in advance.

- Sedat -

2010-12-27 09:12:06

by Stephen Rothwell

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

Hi,

On Mon, 27 Dec 2010 09:04:06 +0100 Sedat Dilek <[email protected]> wrote:
>
> Can you try to upload/push via IPADDR?

I can only upload to master.kernel.org, the rest is done by the mirroring
software. I have no access to any of the other kernel.org machines.

> > The sound tree gained a build failure, so I used the version that would
> > have been in next-20101223.
>
> I thought there was no "next-20101223" :-).

That is why I said "would have been in" :-)

> Can you please upload the patch-diff to
> <http://www.kernel.org/pub/linux/kernel/v2.6/next/>?

If you mean for next-20101223, then there wasn't one. I ran out of time
and just threw away what I had done.

If you mean generally, then (see above) it depends on the mirroring
software.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/

Attachments:

(No filename) (869.00 B)
(No filename) (490.00 B)
Download all attachments

2010-12-27 09:55:35

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

On Mon, Dec 27, 2010 at 10:11 AM, Stephen Rothwell <[email protected]> wrote:
> Hi,
>
> On Mon, 27 Dec 2010 09:04:06 +0100 Sedat Dilek <[email protected]> wrote:
>>
>> Can you try to upload/push via IPADDR?
>
> I can only upload to master.kernel.org, the rest is done by the mirroring
> software. I have no access to any of the other kernel.org machines.
>

I was wondering about still "slow mirrors" as also checking out before
Xmas was very slow.
Now, seeing from an end-users point, the checking-out is just fine.
I tried to clone
"$GIT_MIRROR/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git" where
GIT_MIRROR was:

1. git://130.239.17.7
2. git://199.6.1.166
3. git//git.kernel.org
4. git//git.eu.kernel.org

All checkouts had around 680-690KiB/s.

[...]

>> Can you please upload the patch-diff to
>> <http://www.kernel.org/pub/linux/kernel/v2.6/next/>?
>
> If you mean for next-20101223, then there wasn't one. I ran out of time
> and just threw away what I had done.
>
> If you mean generally, then (see above) it depends on the mirroring
> software.
>

Dunno what you mean with "mirroring software", but I am primarily
interested in the patch-v2.6.37-rc7-next-20101227 than in an updated
linux-next GIT repo.
IMHO, it should be possible to generate this patch from your local GIT
repo and upload the diff-patch to whereever is fast and accessible by
you.
My kernel-build-system has as base a vanilla upstream (here:
2.6.37-rc7) against which I apply an individual patch-series incl. the
linux-next diff-patch.
Hope this helps a bit to understand what I was talking about.

- Sedat -

2010-12-27 11:39:02

by Mark Brown

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

On Mon, Dec 27, 2010 at 05:04:51PM +1100, Stephen Rothwell wrote:

> The sound-asoc tree also had a build failure, so I used the version from
> next-20101221.

What is the problem you are seeing in the sound-asoc tree? I saw a mail
about the sound tree but didn't see any failures reported for ASoC.

2010-12-27 12:09:20

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

On Mon, Dec 27, 2010 at 10:55 AM, Sedat Dilek
<[email protected]> wrote:
> On Mon, Dec 27, 2010 at 10:11 AM, Stephen Rothwell <[email protected]> wrote:
>> Hi,
>>
>> On Mon, 27 Dec 2010 09:04:06 +0100 Sedat Dilek <[email protected]> wrote:
>>>
>>> Can you try to upload/push via IPADDR?
>>
>> I can only upload to master.kernel.org, the rest is done by the mirroring
>> software. I have no access to any of the other kernel.org machines.
>>
>
> I was wondering about still "slow mirrors" as also checking out before
> Xmas was very slow.
> Now, seeing from an end-users point, the checking-out is just fine.
> I tried to clone
> "$GIT_MIRROR/pub/scm/linux/kernel/git/npiggin/linux-npiggin.git" where
> GIT_MIRROR was:
>
> 1. git://130.239.17.7
> 2. git://199.6.1.166
> 3. git//git.kernel.org
> 4. git//git.eu.kernel.org
>
> All checkouts had around 680-690KiB/s.
>

DAMN!
The above was with cloning the vfs-tree from Nick Piggin, with
linux-next GIT it is a difference from where you clone (from my
GeoIP-location):

$ git clone git://130.239.17.7/pub/scm/linux/kernel/git/next/linux-next.git
Cloning into linux-next...
remote: Counting objects: 3164616, done.
remote: Compressing objects: 100% (416281/416281), done.
remote: Total 3164616 (delta 2756821), reused 3128824 (delta 2721031)
Receiving objects: 100% (3164616/3164616), 535.89 MiB | 685 KiB/s, done.
Resolving deltas: 100% (2756821/2756821), done.

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Cloning into linux-next...
remote: Counting objects: 3164616, done.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Anyway, it would be great if someone of the resposibles for the
kernel-mirrors would take care of these problems.

- Sedat -

2010-12-27 14:36:52

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

On 27.12.2010 07:04, Stephen Rothwell wrote:

Hello,

I noticed that after first reboot with this kernel that my MP3
collection in mocp layed on Ext4 fs opens painfully slow. It is not my
mistake, because I always do it the same way, new kernel, then music on.
The problem is not present in rc7-git4. I could measure it in some way
(timing ls -la in tht dir?) if somebody needs it.

Regards,

Piotr Hosowicz

--
Demokracja to kult szakali wyznawany przez os?y (Henry Louis Mencken)
NP: Peter Green Splinter Group - Big Change Is Gonna Come
NB: 2.6.37-rc7-next-20101227

2010-12-27 14:48:30

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

2010/12/27 Piotr Hosowicz <[email protected]>:
> On 27.12.2010 07:04, Stephen Rothwell wrote:
>
> Hello,
>
> I noticed that after first reboot with this kernel that my MP3 collection in
> mocp layed on Ext4 fs opens painfully slow. It is not my mistake, because I
> always do it the same way, new kernel, then music on. The problem is not
> present in rc7-git4. I could measure it in some way (timing ls -la in tht
> dir?) if somebody needs it.
>
> Regards,
>
> Piotr Hosowicz
>

You tried mblk_io_submit mount-option for that partition?

- Sedat -

2010-12-27 14:58:03

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

On 27.12.2010 15:48, Sedat Dilek wrote:
> 2010/12/27 Piotr Hosowicz<[email protected]>:
>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>
>> Hello,
>>
>> I noticed that after first reboot with this kernel that my MP3 collection in
>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake, because I
>> always do it the same way, new kernel, then music on. The problem is not
>> present in rc7-git4. I could measure it in some way (timing ls -la in tht
>> dir?) if somebody needs it.
>>
>> Regards,
>>
>> Piotr Hosowicz
>>
>
> You tried mblk_io_submit mount-option for that partition?

No, I do not use it, I do not even know what it is. My options are:

/dev/sda2 on / type ext4 (rw,errors=remount-ro)

Regards,

Piotr Hosowicz

--
Jest jedna korzy?? z posiadania TV - jak dobrze
rozregulujesz odbiornik, trafisz na promieniowanie
mikrofalowe z pocz?tk?w Wszech?wiata.
NP: Peter Green Splinter Group - Burglar
NB: 2.6.37-rc7-next-20101227

2010-12-27 15:08:14

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

2010/12/27 Piotr Hosowicz <[email protected]>:
> On 27.12.2010 15:48, Sedat Dilek wrote:
>>
>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>
>>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>>
>>> Hello,
>>>
>>> I noticed that after first reboot with this kernel that my MP3 collection
>>> in
>>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake, because
>>> I
>>> always do it the same way, new kernel, then music on. The problem is not
>>> present in rc7-git4. I could measure it in some way (timing ls -la in tht
>>> dir?) if somebody needs it.
>>>
>>> Regards,
>>>
>>> Piotr Hosowicz
>>>
>>
>> You tried mblk_io_submit mount-option for that partition?
>
> No, I do not use it, I do not even know what it is. My options are:
>
> /dev/sda2 on / type ext4 (rw,errors=remount-ro)
>

Have a closer look at "ext4: Turn off multiple page-io submission by default"

- Sedat -

[1] http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commit;h=1449032be17abb69116dbc393f67ceb8bd034f92

2010-12-27 15:13:59

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

On 27.12.2010 16:08, Sedat Dilek wrote:
> 2010/12/27 Piotr Hosowicz<[email protected]>:
>> On 27.12.2010 15:48, Sedat Dilek wrote:
>>>
>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>
>>>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>>>
>>>> Hello,
>>>>
>>>> I noticed that after first reboot with this kernel that my MP3 collection
>>>> in
>>>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake, because
>>>> I
>>>> always do it the same way, new kernel, then music on. The problem is not
>>>> present in rc7-git4. I could measure it in some way (timing ls -la in tht
>>>> dir?) if somebody needs it.
>>>>
>>>> Regards,
>>>>
>>>> Piotr Hosowicz
>>>>
>>>
>>> You tried mblk_io_submit mount-option for that partition?
>>
>> No, I do not use it, I do not even know what it is. My options are:
>>
>> /dev/sda2 on / type ext4 (rw,errors=remount-ro)
>>
>
> Have a closer look at "ext4: Turn off multiple page-io submission by default"

I tried to Google for mblk_io_submit but I didn't find anything helpful.
Could you tell me how should I add this option in fstab and what will be
its effect?

Regards and thanks in advance,

Piotr Hosowicz

--
R??nica mi?dzy PiS, a PO jest taka, ?e PO nie zro-
bi?a liberalizacji, a PiS nie zrobi? lustracji.
NP: Peter Green Splinter Group - I Can't Help Myself
NB: 2.6.37-rc7-next-20101227

2010-12-27 15:20:34

by Stephen Rothwell

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

Hi Mark,

On Mon, 27 Dec 2010 11:38:58 +0000 Mark Brown <[email protected]> wrote:
>
> On Mon, Dec 27, 2010 at 05:04:51PM +1100, Stephen Rothwell wrote:
>
> > The sound-asoc tree also had a build failure, so I used the version from
> > next-20101221.
>
> What is the problem you are seeing in the sound-asoc tree? I saw a mail
> about the sound tree but didn't see any failures reported for ASoC.

I got this error after merging the sound tree:

ERROR: "__tracepoint_snd_soc_jack_irq" [sound/soc/codecs/snd-soc-wm8962.ko] undefined!

after that, I merged the old version of the sound tree. I then merged
the sound-asoc tree and go the same error. I presumed that you had fixed
the other error:

ERROR: "__tracepoint_snd_soc_jack_irq" [sound/soc/codecs/snd-soc-wm8903.ko] undefined!

in the sound-asoc tree and then that version of the sound-asoc tree had
been merged into the sound tree.

--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/

Attachments:

(No filename) (0.99 kB)
(No filename) (490.00 B)
Download all attachments

2010-12-27 15:38:33

by Mark Brown

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

On Tue, Dec 28, 2010 at 02:20:27AM +1100, Stephen Rothwell wrote:

> I got this error after merging the sound tree:

> ERROR: "__tracepoint_snd_soc_jack_irq" [sound/soc/codecs/snd-soc-wm8962.ko] undefined!

> after that, I merged the old version of the sound tree. I then merged
> the sound-asoc tree and go the same error. I presumed that you had fixed
> the other error:

> ERROR: "__tracepoint_snd_soc_jack_irq" [sound/soc/codecs/snd-soc-wm8903.ko] undefined!

> in the sound-asoc tree and then that version of the sound-asoc tree had
> been merged into the sound tree.

To my knowledge I'd fixed everything. However, it looks like there's a
typo in the wm8962 ifdef to work around the x86 failure which was
causing the problem; since you hadn't mentioned that you'd encountered
any issue after I'd done the previous fix I'd no idea that this had
happened and it had appeared that the problem with Takashi's tree was
simply that he'd not merged up the fix.

Fixed now, anyway. Please do report if you see any more issues.

2010-12-27 15:45:43

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

On 27.12.2010 16:13, Piotr Hosowicz wrote:
> On 27.12.2010 16:08, Sedat Dilek wrote:
>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>> On 27.12.2010 15:48, Sedat Dilek wrote:
>>>>
>>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>>
>>>>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I noticed that after first reboot with this kernel that my MP3
>>>>> collection
>>>>> in
>>>>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake,
>>>>> because
>>>>> I
>>>>> always do it the same way, new kernel, then music on. The problem
>>>>> is not
>>>>> present in rc7-git4. I could measure it in some way (timing ls -la
>>>>> in tht
>>>>> dir?) if somebody needs it.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Piotr Hosowicz
>>>>>
>>>>
>>>> You tried mblk_io_submit mount-option for that partition?
>>>
>>> No, I do not use it, I do not even know what it is. My options are:
>>>
>>> /dev/sda2 on / type ext4 (rw,errors=remount-ro)
>>>
>>
>> Have a closer look at "ext4: Turn off multiple page-io submission by
>> default"
>
> I tried to Google for mblk_io_submit but I didn't find anything helpful.
> Could you tell me how should I add this option in fstab and what will be
> its effect?

As far as I understand that option regards writing, not reading. The
symptoms I described occured while reading only.

Regards,

Piotr Hosowicz

--
TV: "W tej chwili, ?e si? tak wyra??, zaliczonych mamy 17 zawodniczek."
NP: Peter Green Splinter Group - Say That You Want To
NB: 2.6.37-rc7-next-20101227

2010-12-27 16:16:43

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

2010/12/27 Piotr Hosowicz <[email protected]>:
> On 27.12.2010 16:13, Piotr Hosowicz wrote:
>>
>> On 27.12.2010 16:08, Sedat Dilek wrote:
>>>
>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>
>>>> On 27.12.2010 15:48, Sedat Dilek wrote:
>>>>>
>>>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>>>
>>>>>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I noticed that after first reboot with this kernel that my MP3
>>>>>> collection
>>>>>> in
>>>>>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake,
>>>>>> because
>>>>>> I
>>>>>> always do it the same way, new kernel, then music on. The problem
>>>>>> is not
>>>>>> present in rc7-git4. I could measure it in some way (timing ls -la
>>>>>> in tht
>>>>>> dir?) if somebody needs it.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Piotr Hosowicz
>>>>>>
>>>>>
>>>>> You tried mblk_io_submit mount-option for that partition?
>>>>
>>>> No, I do not use it, I do not even know what it is. My options are:
>>>>
>>>> /dev/sda2 on / type ext4 (rw,errors=remount-ro)
>>>>
>>>
>>> Have a closer look at "ext4: Turn off multiple page-io submission by
>>> default"
>>
>> I tried to Google for mblk_io_submit but I didn't find anything helpful.
>> Could you tell me how should I add this option in fstab and what will be
>> its effect?
>
> As far as I understand that option regards writing, not reading. The
> symptoms I described occured while reading only.
>

That's the only performance issue I am aware of in ext4 in recent time.
Why don't you try it and present some numbers in transfer ratio (write, read)?

- Sedat -

2010-12-27 19:23:51

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27 (drivers/target/)

On Mon, 27 Dec 2010 17:04:51 +1100 Stephen Rothwell wrote:

> Hi all,
>
> [The mirroring on kernel.org is running slowly]

yep :(

> Changes since 20101221:

When CONFIG_SCSI is not enabled:

ERROR: "scsi_device_type" [drivers/target/target_core_mod.ko] undefined!

from target_core_transport.c::1586:

printk(" Type: %s ", scsi_device_type(device_type));

Also please update MAINTAINERS for drivers/target/.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts: http://www.xenotime.net/linux/recipes/

2010-12-27 19:56:18

[permalink] [raw]

Subject: [PATCH -next] ocfs2: fix build for OCFS2_FS_STATS not enabled

From: Randy Dunlap <[email protected]>

When CONFIG_OCFS2_FS_STATS is not enabled:

fs/ocfs2/cluster/tcp.c:1254: error: implicit declaration of function 'o2net_update_recv_stats'

Signed-off-by: Randy Dunlap <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Cc: [email protected]
---
fs/ocfs2/cluster/tcp.c | 2 ++
1 file changed, 2 insertions(+)

--- linux-next-20101227.orig/fs/ocfs2/cluster/tcp.c
+++ linux-next-20101227/fs/ocfs2/cluster/tcp.c
@@ -257,6 +257,8 @@ static void o2net_update_recv_stats(stru

# define o2net_update_send_stats(a, b)

+# define o2net_update_recv_stats(sc)
+
#endif /* CONFIG_OCFS2_FS_STATS */

static inline int o2net_reconnect_delay(void)

2010-12-27 19:58:47

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27 (drivers/target)

On Mon, 27 Dec 2010 17:04:51 +1100 Stephen Rothwell wrote:

> Hi all,
>
> [The mirroring on kernel.org is running slowly]
>
> Changes since 20101221:
>
> Linus' tree lost its build failure.

Hi Nick,

Please test building target code when CONFIG_BLOCK is not enabled.

When CONFIG_BLOCK is not enabled, drivers/target/ gets a boat load of build errors.

Should TCM_IBLOCK depend on BLOCK? That fixes lots of the build errors,
but not all of them.

The header file include/target/target_core_base.h uses struct queue_limits,
so it should #include <linux/blkdev.h>.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts: http://www.xenotime.net/linux/recipes/

2010-12-27 20:54:17

by Joel Becker

[permalink] [raw]

Subject: Re: [PATCH -next] ocfs2: fix build for OCFS2_FS_STATS not enabled

On Mon, Dec 27, 2010 at 11:55:08AM -0800, Randy Dunlap wrote:
> From: Randy Dunlap <[email protected]>
>
> When CONFIG_OCFS2_FS_STATS is not enabled:
>
> fs/ocfs2/cluster/tcp.c:1254: error: implicit declaration of function 'o2net_update_recv_stats'
>
> Signed-off-by: Randy Dunlap <[email protected]>
> Cc: Mark Fasheh <[email protected]>
> Cc: Joel Becker <[email protected]>
> Cc: [email protected]

Acked-by: Joel Becker <[email protected]>

Do you want to push it or would you like me to?

Joel

--

"But all my words come back to me
In shades of mediocrity.
Like emptiness in harmony
I need someone to comfort me."

Joel Becker
Senior Development Manager
Oracle
E-mail: [email protected]
Phone: (650) 506-8127

2010-12-27 21:43:50

[permalink] [raw]

Subject: Re: [PATCH -next] ocfs2: fix build for OCFS2_FS_STATS not enabled

On 12/27/10 12:52, Joel Becker wrote:
> On Mon, Dec 27, 2010 at 11:55:08AM -0800, Randy Dunlap wrote:
>> From: Randy Dunlap <[email protected]>
>>
>> When CONFIG_OCFS2_FS_STATS is not enabled:
>>
>> fs/ocfs2/cluster/tcp.c:1254: error: implicit declaration of function 'o2net_update_recv_stats'
>>
>> Signed-off-by: Randy Dunlap <[email protected]>
>> Cc: Mark Fasheh <[email protected]>
>> Cc: Joel Becker <[email protected]>
>> Cc: [email protected]
>
> Acked-by: Joel Becker <[email protected]>
>
> Do you want to push it or would you like me to?

You, please.

--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts: http://www.xenotime.net/linux/recipes/

2010-12-27 22:53:38

by Nicholas A. Bellinger

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27 (drivers/target/)

On Mon, 2010-12-27 at 11:21 -0800, Randy Dunlap wrote:
> On Mon, 27 Dec 2010 17:04:51 +1100 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > [The mirroring on kernel.org is running slowly]
>
> yep :(
>
> > Changes since 20101221:
>
>
> When CONFIG_SCSI is not enabled:
>
> ERROR: "scsi_device_type" [drivers/target/target_core_mod.ko] undefined!
>
> from target_core_transport.c::1586:
>
> printk(" Type: %s ", scsi_device_type(device_type));
>

Hi Randy and Stephen,

As there is really no a reason for building CONFIG_TARGET_CORE w/o
CONFIG_SCSI && CONFIG_BLOCK, the following patch has been added to the
new linux-next target tree here:

target: Add SCSI and BLOCK depends for TARGET_CORE
http://git.kernel.org/?p=linux/kernel/git/nab/linux-next.git;a=commitdiff;h=15c8da9639029ac337dd2f0bb67010de62d4b724

>
> Also please update MAINTAINERS for drivers/target/.
>

Also added here, thanks for the reminder:

target: Add drivers/target/ entry to MAINTAINERS
http://git.kernel.org/?p=linux/kernel/git/nab/linux-next.git;a=commitdiff;h=85356c6c328b3c4add3d240e387087a76a469028

Best Regards,

--nab

2010-12-27 22:55:36

by Nicholas A. Bellinger

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27 (drivers/target)

On Mon, 2010-12-27 at 11:57 -0800, Randy Dunlap wrote:
> On Mon, 27 Dec 2010 17:04:51 +1100 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > [The mirroring on kernel.org is running slowly]
> >
> > Changes since 20101221:
> >
> > Linus' tree lost its build failure.
>
>
> Hi Nick,
>
> Please test building target code when CONFIG_BLOCK is not enabled.
>
> When CONFIG_BLOCK is not enabled, drivers/target/ gets a boat load of build errors.
>
> Should TCM_IBLOCK depend on BLOCK? That fixes lots of the build errors,
> but not all of them.
>
>
> The header file include/target/target_core_base.h uses struct queue_limits,
> so it should #include <linux/blkdev.h>.
>
>

Added the missing include here:

target: Add linux/blkdev.h include in target_core_base.h
http://git.kernel.org/?p=linux/kernel/git/nab/linux-next.git;a=commitdiff;h=e8bd07d3a525e71b424d308fc5084b89a6456bb2

Thanks Randy!

--nab

2010-12-28 14:27:29

[permalink] [raw]

Subject: Re: linux-next: Tree for December 27

On 27.12.2010 17:16, Sedat Dilek wrote:
> 2010/12/27 Piotr Hosowicz<[email protected]>:
>> On 27.12.2010 16:13, Piotr Hosowicz wrote:
>>>
>>> On 27.12.2010 16:08, Sedat Dilek wrote:
>>>>
>>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>>
>>>>> On 27.12.2010 15:48, Sedat Dilek wrote:
>>>>>>
>>>>>> 2010/12/27 Piotr Hosowicz<[email protected]>:
>>>>>>>
>>>>>>> On 27.12.2010 07:04, Stephen Rothwell wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I noticed that after first reboot with this kernel that my MP3
>>>>>>> collection
>>>>>>> in
>>>>>>> mocp layed on Ext4 fs opens painfully slow. It is not my mistake,
>>>>>>> because
>>>>>>> I
>>>>>>> always do it the same way, new kernel, then music on. The problem
>>>>>>> is not
>>>>>>> present in rc7-git4. I could measure it in some way (timing ls -la
>>>>>>> in tht
>>>>>>> dir?) if somebody needs it.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Piotr Hosowicz
>>>>>>>
>>>>>>
>>>>>> You tried mblk_io_submit mount-option for that partition?
>>>>>
>>>>> No, I do not use it, I do not even know what it is. My options are:
>>>>>
>>>>> /dev/sda2 on / type ext4 (rw,errors=remount-ro)
>>>>>
>>>>
>>>> Have a closer look at "ext4: Turn off multiple page-io submission by
>>>> default"
>>>
>>> I tried to Google for mblk_io_submit but I didn't find anything helpful.
>>> Could you tell me how should I add this option in fstab and what will be
>>> its effect?
>>
>> As far as I understand that option regards writing, not reading. The
>> symptoms I described occured while reading only.
>>
>
> That's the only performance issue I am aware of in ext4 in recent time.
> Why don't you try it and present some numbers in transfer ratio (write, read)?

Ok, I'll try to measure it in shell. Now I am building newest non-next
kernel and the trial script is:

#!/bin/bash

uname -a
mount
cd /data/music
time ls -d *
cd -

This is basically what mocp does when it enters my music directory,
apart from displaying the results in ncurses based UI. Then I'll reboot
with next kernel and run it again. Will it do?

Regards,

Piotr Hosowicz

--
Kto? zapuka? do drzwi.
-Bormann - pomy?la? Stirlitz
-Tak, to ja - pomy?la? Bormann
NP: Peter Green Splinter Group - Madison Blues
NB: 2.6.37-rc7-20101227-pztidm+

2010-12-28 15:09:34