RE: [Lse-tech] [normal] - Scalability (Locking primitives - peel off dcache lock ) not integrated

[Whalen, M. <mau...@in...>]

Yes, John Villalovos will be taking this over for the rest of this week.

Mauri


-----Original Message-----
From: Tony Abbattista [mailto:abb...@us...]=20
Sent: Monday, June 24, 2002 7:24 PM
To: ha...@li...
Cc: 'be...@us...'; gh...@li...; ha...@li...; Hans-Joach=
im
Tannenberger; Villalovos, John L; 'yo...@us...'; 'kh...@us...';
'Lisa Perry'; 'lse...@li...'; ma...@li...; Ma=
rk
VanderWiele; Whalen, Mauri; Peddibhotla, Rammohan; Selbak, Rolla N; Shure=
ih,
Tariq; randy Kalmeta
Subject: RE: [Lse-tech] [normal] - Scalability (Locking primitives - peel
off dcache lock ) not integrated


Tariq, Mauri,
         Given that Hanna won't be available this week and next week is o=
ur
mandatory vacation, is it possible for Rolla Selbak or John Villalovos to
pick up and complete this integration work?  In general, we agreed to
assist with integration type questions but wanted to avoid applying
resources to perform the integration to the evolving Carrierlinux.org
kernel where your team has the expertise.  Let me know if you can contain
this effort.

                                                   Thanks,
                                                               Tony


Tony Abbattista
Senior Project Manager
Linux Technology Center
abb...@us...
T/L 678-2102
1-512-838-2102



=20

                      hannal@linux.ibm.

                      com                      To:       "Shureih, Tariq"
<tar...@in...>, ma...@li...    =20
                                               cc:
ha...@li..., Ben Rafanello/Austin/IBM@IBMUS, Kent E         =20
                      06/24/2002 06:15          Yoder/Austin/IBM@IBMUS, K=
hoa
Huynh/Austin/IBM@IBMUS, Lisa                     =20
                      PM                        Perry/Beaverton/IBM@IBMUS=
,
"'lse...@li...'"                 =20
=20
<lse...@li...>, "Whalen, Mauri" <mau...@in...=
>,

                                                "Peddibhotla, Rammohan"
<ram...@in...>, Hans                =20
=20
Tannenberger/Beaverton/IBM@IBMUS, gh...@li..., Mark

=20
VanderWiele/Austin/IBM@IBMUS, Tony Abbattista/Austin/IBM@ibmus, "Selbak,
Rolla=20
                                                N"
<rol...@in...>, "Villalovos, John L"                         =
  =20
=20
<joh...@in...>

                                               Subject:  RE: [Lse-tech]
[normal] - Scalability (Locking primitives - peel     =20
                                                   off dcache lock ) not
integrated                                           =20
=20

=20

=20





Tariq,

             Hi. I am going to be out of town until the 30th as well.
Unless someone else at Intel can integrate this patch it will
have to wait for a week.

Thanks.

Hanna


--On Monday, June 24, 2002 15:44:22 -0700 "Shureih, Tariq"
<tar...@in...> wrote:

> Hanna:
>
> I attempted to integrate the rcu_ltimer patch into our progressive tree
and
> got the failures below.
>
> My previous email to the list I mentioned how and where you can get a
hold
> of the latest copy of our kernel source.
>
> If you need any help between tomorrow and the 30th, please contact Roll=
a
> Selbak and John Villalovos, but emails are CCed.
>
> Thanx
>
>
> Master Tariq:~/work/kernel/linux-2.4.18/src$: patch --dry-run -p1 <
> ../rcu_ltimer-2.4.18-1.patch
> patching file arch/alpha/kernel/smp.c
> patching file arch/i386/kernel/apic.c
> Hunk #2 succeeded at 990 (offset 20 lines).
> patching file arch/ia64/kernel/smp.c
> Hunk #2 succeeded at 335 (offset 33 lines).
> patching file arch/mips64/sgi-ip27/ip27-timer.c
> patching file arch/ppc/kernel/smp.c
> patching file arch/s390/kernel/smp.c
> patching file arch/s390x/kernel/smp.c
> patching file arch/sparc/kernel/sun4d_smp.c
> patching file arch/sparc/kernel/sun4m_smp.c
> patching file arch/sparc64/kernel/smp.c
> patching file include/linux/rcupdate.h
> patching file init/main.c
> Hunk #1 succeeded at 28 with fuzz 1 (offset 1 line).
> Hunk #2 succeeded at 565 (offset 7 lines).
> patching file kernel/Makefile
> Hunk #1 FAILED at 9.
> 1 out of 1 hunk FAILED -- saving rejects to file kernel/Makefile.rej
> patching file kernel/rcupdate.c
> patching file kernel/sched.c
> Hunk #1 FAILED at 29.
> Hunk #2 FAILED at 637.
> 2 out of 2 hunks FAILED -- saving rejects to file kernel/sched.c.rej
> patching file kernel/timer.c
> Hunk #1 succeeded at 22 with fuzz 2.
> Hunk #2 succeeded at 956 with fuzz 2 (offset 280 lines).
>
> --
> Tariq =88
>
> -----Original Message-----
> From: Hanna Linder [mailto:ha...@us...]
> Sent: Friday, June 21, 2002 4:12 PM
> To: Shureih, Tariq; 'ma...@in...'
> Cc: Hanna Linder; 'be...@us...'; 'yo...@us...';
'kh...@us...';
> 'Lisa Perry'; 'lse...@li...'; Whalen, Mauri;
Peddibhotla,
> Rammohan; Hans-Joachim Tannenberger; gh...@us...; ma...@us...;
> abb...@us...
> Subject: RE: [Lse-tech] [normal] - Scalability (Locking primitives - pe=
el
> off dcache lock ) not integrated
>
>
> Hello,
>
>            I have put the rcu framework patch on the CPR and
> it should have notified you it is there. The patch is called:
> rcu_ltimer-2.4.18-1.patch This is the first patch you will apply
> to a clean 2.4.18 kernel followed by the files_struct_rcu patch
> then the fast_walk+dcache_rcu patch. I have tested that it
> all applies cleanly.
>
>            You mentioned below that you are not using the
> kernel.org 2.4.18 kernel. That does appear to be the problem
> with these patches not applying cleanly. Is that kernel you
> are using publicly available for download? We will not be
> able to make patches against it if we dont have the kernel.
>
> Thanks.
>
> Hanna
>
>
> --On Friday, June 21, 2002 10:18:40 -0700 "Shureih, Tariq"
> <tar...@in...> wrote:
>
>> The problem I am running in, in my opinion, has no relation as of yet =
to
> the
>> missing -- yet to be delivered -- rcu framework patch.
>>
>> To give you a background, our kernel is not a stock kernel.org kernel.
>>
>> Our source tree is a progressive development tree where multiple patch=
es
> are
>> applied and integrated together to provide multiple functionality.
>>
>> The dcache file I sent is obviously not a "clean" file as provided by
>> kernel.org's distribution of the kernel 2.4.18 source.
>> It has been modified by another patch (feature) that our TLT kernel
>> supports.
>>
>> I sent the two files, the .rej and the original (from our tree) in ord=
er
> for
>> the owner of the "Scalability -Locking primitives- peel off dcache loc=
k"
> to
>> see what the other patch added and probably modify the patch to
> accommodate
>> the changes done by the other patch (we applied) to the dcache.h file.
>>
>>
>> --
>> Tariq ?
>>
>> -----Original Message-----
>> From: Maneesh Soni [mailto:ma...@in...]
>> Sent: Friday, June 21, 2002 1:31 AM
>> To: Shureih, Tariq; Hanna Linder
>> Cc: 'be...@us...'; 'yo...@us...'; 'kh...@us...'; 'Lisa
> Perry';
>> 'lse...@li...'; Whalen, Mauri; Peddibhotla, Rammohan
>> Subject: Re: [Lse-tech] [normal] - Scalability (Locking primitives -
peel
>> off dcache lock ) not integrated
>>
>>
>> Hi Tariq, hanna
>>
>> There cannot be a conflict between these two patches, atleast in
>> include/linux/dcache.h file simply because it is not a common file
between
>> the
>> two patches. Both patches are independent and not related. But it is
true
>> that both patches need rcu frame-work patch (not there yet) to get the=
m
>> build.
>>
>> I also tried to apply both patches on 2.4.18 kernel (from kernel.org)
and
>> found
>> that when patch 2 is applied after patch 1, both apply cleanly. And no=
t
>> very cleanly in the reverse order.
>>
>> Now the conflict you are seeing after applying patch 1
>> (Fast_walk+dcache_rcu...)
>> could be because of some other patch applied on clean 2.4.18 (from
>> kernel.org)
>> src tree.
>>
>> The dcache.h file you sent is not same as in clean 2.4.18 kernel. And =
as

>> fast_walk+dcache_rcuA2-2.4.18.patch was built for clean 2.4.18 src tre=
e,
> the
>>
>> conflict has to be resolved manually.
>>
>> As you seem not able to do it I have done that for you this time. I
could
>> not
>> generate a new patch for TLT kernel build so I have just modified the
>> dcache.h
>> file you have sent. Please find the file attached to this mail.
>>
>> Regards,
>> Maneesh
>>
>>
>> PS: I will be leaving for OLS today so will not access this emailid ti=
ll

>>     2nd Jul.
>>
>> On Thu, Jun 20, 2002 at 03:19:19PM -0700, Shureih, Tariq wrote:
>>> All:
>>>
>>>
>>>
>>> I received the Locking primitives - peel off dcache lock and attempte=
d
to
>>> integrate it into our TLT kernel build.
>>>
>>>
>>>
>>> The download site included two (2) patches:
>>>
>>> 1- Fast_walk+dcache_rcuA2-2.4.16.patch.gz
>>>
>>> 2- Files_struct_rcu-2.4.18-07.patch.gz
>>>
>>>
>>>
>>> Patch 2 depends on patch 1 to be applied first.
>>>
>>>
>>>
>>> Patch 2 applies just fine; however, patch 1 does not and conflicts wi=
th
>>> another feature in our source tree.  Upon trying to resolve it, it
turned
>>> out that some knowledge is required I do not have.
>>>
>>>
>>>
>>> The conflict is in one file "linux-2.4.18/src/include/linux/dcache.h".

>>>
>>> I attached the original file from our source tree as well as the
>>> "dcache.h.rej" file showing the area of conflict.
>>>
>>>
>>>
>>> This feature will not be in the build.
>>>
>>>
>>>
>>> Bugzilla item number: 582
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ^-^-^-^-^-^-^-^-
>>>
>>> Tariq Shureih
>>>
>>> Software Engineering & Integration
>>>
>>> Intel Corporation -- TSP
>>>
>>> (503) 677-6776
>>>
>>> tariq.shureih@Intel.com <mailto:tariq.shureih@Intel.com>
>>>
>>>
>>>
>>
>>
>>
>>
>> --
>> Maneesh Soni
>> IBM Linux Technology Center,
>> IBM India Software Lab, Bangalore.
>> Phone: +91-80-5044999 email: ma...@in...
>> http://lse.sourceforge.net/locking/rcupdate.html
>>
>
>