Re: [PATCH 0/9] make struct drm_mm_node embeddable

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Sedat Dilek]

[ Please CC me I am not subscribed to dri-devel ML ]

[ QUOTE ]
Hi all,

This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:

- If struct drm_mm_node is provided, no allocations need to be done anymore
  in drm_mm. It looks like some decent surgery, but ttm should be able to
  drop its preallocation dance.
- void *priv is back, but done right ;)
- Avoids a pointer chase when lru-scanning in i915 and saves a few bytes.

As a proof of concept I've converted i915. Beware though, the drm/i915
patches depend on my direct-gtt patches (which are actually the reason for
this series here).

Tested on my i855gm, i945gme, ironlake and agp rv570.

Comments, flames, reviews highly welcome.
[ /QUOTE ]

Against which GIT tree or linux-next version are these patchset for?

- Sedat -


$ cd ~/src/linux-2.6/linux-2.6.37-rc1

$ echo $SINGLE_KERNEL_VARIANT
i386_none_686

$ LC_ALL=C fakeroot make -f debian/rules.gen
setup_${SINGLE_KERNEL_VARIANT} 2>&1 | tee ../setup.log
make -f debian/rules.real setup-flavour ABINAME='' ARCH='i386'
COMPILER='gcc-4.4' FEATURESET='none' FLAVOUR='686'
INITRD_CMD='update-initramfs' KCONFIG='debian/config/config
debian/config/kernelarch-x86/config
debian/config/kernelarch-x86/config-arch-32
debian/config/i386/none/config.686' KERNEL_ARCH='x86'
LOCALVERSION='-686' LOCALVERSION_HEADERS='' LOCALVERSION_IMAGE='-686'
MAJOR='2.6' MODULES='True'
SOURCEVERSION='2.6.37~rc1-11~next~20101112.1~dileks.1' TYPE='plain'
UPSTREAMVERSION='2.6.37-rc1' VERSION='2.6.37'
make[1]: Entering directory `/home/sd/src/linux-2.6/linux-2.6.37-rc1'
rm -rf 'debian/build/source'
mkdir -p 'debian/build/source'
cp -al COPYING CREDITS Documentation Kbuild Kconfig MAINTAINERS
Makefile README REPORTING-BUGS arch block crypto drivers firmware fs
include init ipc kernel lib mm net samples scripts security sound
tools usr virt .gitignore .mailmap 'debian/build/source'
cd 'debian/build/source'; python
'/home/sd/src/linux-2.6/linux-2.6.37-rc1/debian/bin/patch.apply'
--overwrite-home='/home/sd/src/linux-2.6/linux-2.6.37-rc1/debian/patches'
/home/sd/src/linux-2.6/linux-2.6.37-rc1/debian/bin/patch.apply:81:
DeprecationWarning: functions overriding warnings.showwarning() must
support the 'line' argument
  warn('No %s file, assuming Debian Linux %s' % (self._file, upstream))
Warning: No version.Debian file, assuming Debian Linux 2.6.37~rc1
1 out of 11 hunks FAILED -- saving rejects to file drivers/gpu/drm/drm_mm.c.rej
Error: Patch failed
--> Try to apply base.
  (+) OK   linux-next/patch-v2.6.37-rc1-next-20101112
  (+) OK   linux-next/0001-Remove-localversion-next.patch
  (+) OK   for-linux-next/drm-next/make-struct-drm_mm_node-embeddable/1-9-drm-nouveau-don-t-munge-in-drm_mm-internals.patch
  (+) FAIL for-linux-next/drm-next/make-struct-drm_mm_node-embeddable/2-9-drm-mm-track-free-areas-implicitly.patch
make[1]: *** [debian/stamps/source] Error 1
make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc1'
make: *** [setup_i386_none_686_real] Error 2

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Chris Wilson]

On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> [ Please CC me I am not subscribed to dri-devel ML ]
> 
> [ QUOTE ]
> As a proof of concept I've converted i915. Beware though, the drm/i915
> patches depend on my direct-gtt patches (which are actually the reason for
> this series here).
> 
> [ /QUOTE ]
> 
> Against which GIT tree or linux-next version are these patchset for?

git://anongit.freedesktop.org/~danvet/drm direct-gtt
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Sedat Dilek]

On Sun, Nov 14, 2010 at 3:38 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>> [ Please CC me I am not subscribed to dri-devel ML ]
>>
>> [ QUOTE ]
>> As a proof of concept I've converted i915. Beware though, the drm/i915
>> patches depend on my direct-gtt patches (which are actually the reason for
>> this series here).
>>
>> [ /QUOTE ]
>>
>> Against which GIT tree or linux-next version are these patchset for?
>
> git://anongit.freedesktop.org/~danvet/drm direct-gtt
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>

Thank you for the pointer to the right GIT repository and branch.
Looks like [1] has Daniel's patchset (9 patches) already included.

To attract more people for testing or joining it would be appreciated
these interesting work would be (re)based on Dave's drm-next GIT tree,
as this one is going to linux-next.

Or is drm-next/linux-next work for intel-gfxcards done elsewhere?

Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
Linus-tree is causing conflicts.

- Sedat -

[1] http://cgit.freedesktop.org/~danvet/drm/log/?h=embed-gtt-space

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Daniel Vetter]

On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
> Linus-tree is causing conflicts.

I've just retested merging with drm-core-next / drm-next and the core
drm_mm parts merge without conflict. The i915 parts fail all over due to
conflicts with other ongoing stuff. As I've said, these patches are just
proof-of-concept, I need to redo them (and coordinate merging with Chris
Wilson). So either test my embed-gtt-space branch to also enjoy the i915
patches. Or only test the drm core changes.

-Daniel

> [1] http://cgit.freedesktop.org/~danvet/drm/log/?h=embed-gtt-space

-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Sedat Dilek]

On Sun, Nov 14, 2010 at 5:13 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
>> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
>> Linus-tree is causing conflicts.
>
> I've just retested merging with drm-core-next / drm-next and the core
> drm_mm parts merge without conflict. The i915 parts fail all over due to
> conflicts with other ongoing stuff. As I've said, these patches are just
> proof-of-concept, I need to redo them (and coordinate merging with Chris
> Wilson). So either test my embed-gtt-space branch to also enjoy the i915
> patches. Or only test the drm core changes.
>

If you could geneate a patchset w/o i915 parts for testing would be cool.
Thanks in advance.

- Sedat -

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Daniel Vetter]

On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
> If you could geneate a patchset w/o i915 parts for testing would be cool.
> Thanks in advance.

Just drop patches 5-9 (you can apply patch 8 without any problems, it's
just not gonna do anything without patch 9 ;). After all, this patch
series is supposed to be bisectable, so stopping anywhere in between
should result in a working kernel.

-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Sedat Dilek]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>> Thanks in advance.
>
> Just drop patches 5-9 (you can apply patch 8 without any problems, it's
> just not gonna do anything without patch 9 ;). After all, this patch
> series is supposed to be bisectable, so stopping anywhere in between
> should result in a working kernel.
>
> -Daniel
> --
> Daniel Vetter
> Mail: daniel@ffwll.ch
> Mobile: +41 (0)79 365 57 48
>

Njet :-(

I am cloning linux-next GIT and pull into drm-next to see if there is
sth. missing.

- Sedat -

[-- Attachment #2: njet.txt --]
[-- Type: text/plain, Size: 4036 bytes --]

sd@tbox:~/src/linux-2.6/linux-2.6.37-rc1$ grep ^+ debian/patches/series/base
+ linux-next/patch-v2.6.37-rc1-next-20101112
+ linux-next/0001-Remove-localversion-next.patch
+ for-linux-next/next-iwlwifi-fix-modular-legacy-build-errors.patch
+ mm-fixes/cgroup-Avoid-a-memset-by-using-vzalloc.patch
+ mm-fixes/kmemleak-remove-memset-by-using-kzalloc.patch
+ linux-2.6-block-for-2.6.38-core/linux-2.6-block-for-2.6.38-core.patch
+ tpm-fix/tpm-Autodetect-itpm-devices.patch
+ for-drm-next/make-struct-drm_mm_node-embeddable/1-9-drm-nouveau-don-t-munge-in-drm_mm-internals.patch
+ for-drm-next/make-struct-drm_mm_node-embeddable/2-9-drm-mm-track-free-areas-implicitly.patch
+ for-drm-next/make-struct-drm_mm_node-embeddable/3-9-drm-mm-extract-node-insert-helper-functions.patch
+ for-drm-next/make-struct-drm_mm_node-embeddable/4-9-drm-mm-add-api-for-embedding-struct-drm_mm_node.patch
+ for-drm-next/make-struct-drm_mm_node-embeddable/8-9-drm-mm-add-helper-to-unwind-scan-state.patch
+ debian/version.patch
+ debian/kernelvariables-2.6.37.patch
+ debian/doc-build-parallel.patch
+ bugfix/ia64/hardcode-arch-script-output.patch
+ bugfix/mips/disable-advansys.patch
+ bugfix/arm/disable-scsi_acard.patch
+ debian/mips-disable-werror.patch
+ bugfix/powerpc/lpar-console.patch
+ features/all/i915-autoload-without-CONFIG_DRM_I915_KMS.patch
+ debian/arch-sh4-fix-uimage-build.patch
+ bugfix/mips/mips-ide-flush-dcache.patch
+ bugfix/all/qla4xxx-Fix-build-on-some-architectures-lacking-64-bit-I-O.patch
+ bugfix/x86/Skip-looking-for-ioapic-overrides-when-ioapics-are-not-present.patch


sd@tbox:~/src/linux-2.6/linux-2.6.37-rc1$ LC_ALL=C fakeroot make -f debian/rules.gen setup_i386_none_686 2>&1 | tee ../setup.log
make -f debian/rules.real setup-flavour ABINAME='' ARCH='i386' COMPILER='gcc-4.4' FEATURESET='none' FLAVOUR='686' INITRD_CMD='update-initramfs' KCONFIG='debian/config/config debian/config/kernelarch-x86/config debian/config/kernelarch-x86/config-arch-32 debian/config/i386/none/config.686' KERNEL_ARCH='x86' LOCALVERSION='-686' LOCALVERSION_HEADERS='' LOCALVERSION_IMAGE='-686' MAJOR='2.6' MODULES='True' SOURCEVERSION='2.6.37~rc1-11~next~20101112.1~dileks.1' TYPE='plain' UPSTREAMVERSION='2.6.37-rc1' VERSION='2.6.37'
make[1]: Entering directory `/home/sd/src/linux-2.6/linux-2.6.37-rc1'
rm -rf 'debian/build/source'
mkdir -p 'debian/build/source'
cp -al COPYING CREDITS Documentation Kbuild Kconfig MAINTAINERS Makefile README REPORTING-BUGS arch block crypto drivers firmware fs include init ipc kernel lib mm net samples scripts security sound tools usr virt .gitignore .mailmap 'debian/build/source'
cd 'debian/build/source'; python '/home/sd/src/linux-2.6/linux-2.6.37-rc1/debian/bin/patch.apply' --overwrite-home='/home/sd/src/linux-2.6/linux-2.6.37-rc1/debian/patches'
/home/sd/src/linux-2.6/linux-2.6.37-rc1/debian/bin/patch.apply:81: DeprecationWarning: functions overriding warnings.showwarning() must support the 'line' argument
  warn('No %s file, assuming Debian Linux %s' % (self._file, upstream))
Warning: No version.Debian file, assuming Debian Linux 2.6.37~rc1
6 out of 11 hunks FAILED -- saving rejects to file drivers/gpu/drm/drm_mm.c.rej
Error: Patch failed
--> Try to apply base.
  (+) OK   linux-next/patch-v2.6.37-rc1-next-20101112
  (+) OK   linux-next/0001-Remove-localversion-next.patch
  (+) OK   for-linux-next/next-iwlwifi-fix-modular-legacy-build-errors.patch
  (+) OK   mm-fixes/cgroup-Avoid-a-memset-by-using-vzalloc.patch
  (+) OK   mm-fixes/kmemleak-remove-memset-by-using-kzalloc.patch
  (+) OK   linux-2.6-block-for-2.6.38-core/linux-2.6-block-for-2.6.38-core.patch
  (+) OK   tpm-fix/tpm-Autodetect-itpm-devices.patch
  (+) OK   for-drm-next/make-struct-drm_mm_node-embeddable/1-9-drm-nouveau-don-t-munge-in-drm_mm-internals.patch
  (+) FAIL for-drm-next/make-struct-drm_mm_node-embeddable/2-9-drm-mm-track-free-areas-implicitly.patch
make[1]: *** [debian/stamps/source] Error 1
make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc1'
make: *** [setup_i386_none_686_real] Error 2


[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Sedat Dilek]

On Sun, Nov 14, 2010 at 6:27 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>>> Thanks in advance.
>>
>> Just drop patches 5-9 (you can apply patch 8 without any problems, it's
>> just not gonna do anything without patch 9 ;). After all, this patch
>> series is supposed to be bisectable, so stopping anywhere in between
>> should result in a working kernel.
>>
>> -Daniel
>> --
>> Daniel Vetter
>> Mail: daniel@ffwll.ch
>> Mobile: +41 (0)79 365 57 48
>>
>
> Njet :-(
>
> I am cloning linux-next GIT and pull into drm-next to see if there is
> sth. missing.
>
> - Sedat -
>

NOPE, linux-next is up-to-date what drm-next concerns.

- Sedat -

sd@tbox:/mnt/sdb5/linux-kernel$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Cloning into linux-next...
remote: Counting objects: 3084175, done.
remote: Compressing objects: 100% (404388/404388), done.
remote: Total 3084175 (delta 2687481), reused 3050014 (delta 2653407)
Receiving objects: 100% (3084175/3084175), 513.53 MiB | 566 KiB/s, done.
Resolving deltas: 100% (2687481/2687481), done.

sd@tbox:/mnt/sdb5/linux-kernel$ tar -cf
files/linux-next_git_next-20101112.tar linux-next/

sd@tbox:/mnt/sdb5/linux-kernel$ cd linux-next/

sd@tbox:/mnt/sdb5/linux-kernel/linux-next$ git pull
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-next
>From git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
 * branch            drm-next   -> FETCH_HEAD
Already up-to-date.

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Daniel Vetter]

On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
> NOPE, linux-next is up-to-date what drm-next concerns.

Sorry for wasting your time, I've totally forgotten about a patch in
drm-intel-next
(git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git),
namely:

commit d935cc61d466f6cc7514032835f4fc379cb7e2ca
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Sep 16 15:13:11 2010 +0200

    drm_mm: add support for range-restricted fair-lru scans

That one's necessary, too.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Sedat Dilek]

Found myself :-)

$ ls -l 0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
-rw-r--r-- 1 sd sd 3620 14. Nov 19:15
0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch

On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
>> NOPE, linux-next is up-to-date what drm-next concerns.
>
> Sorry for wasting your time, I've totally forgotten about a patch in
> drm-intel-next
> (git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git),
> namely:
>
> commit d935cc61d466f6cc7514032835f4fc379cb7e2ca
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Thu Sep 16 15:13:11 2010 +0200
>
>    drm_mm: add support for range-restricted fair-lru scans
>
> That one's necessary, too.
>
> Yours, Daniel
> --
> Daniel Vetter
> Mail: daniel@ffwll.ch
> Mobile: +41 (0)79 365 57 48
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Sedat Dilek]

On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
>> NOPE, linux-next is up-to-date what drm-next concerns.
>
> Sorry for wasting your time, I've totally forgotten about a patch in
> drm-intel-next
> (git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git),
> namely:
>
> commit d935cc61d466f6cc7514032835f4fc379cb7e2ca
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Thu Sep 16 15:13:11 2010 +0200
>
>    drm_mm: add support for range-restricted fair-lru scans
>
> That one's necessary, too.
>
> Yours, Daniel
> --
> Daniel Vetter
> Mail: daniel@ffwll.ch
> Mobile: +41 (0)79 365 57 48
>

Hmm, I tried with your patches from ML plus missing patch and
extracted patches from ~danvet/drm/embed-gtt-space.
Sth. messed up....

Could be a "big.diff" is needed, *not* a chronological series.
I will do a big.diff from 0081..0089 and apply
0008-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch first.

- Sedat -

sd@tbox:~/src/linux-2.6/linux-2.6.37-rc1$ grep ^+ debian/patches/series/base
+ linux-next/patch-v2.6.37-rc1-next-20101112
+ linux-next/0001-Remove-localversion-next.patch
+ for-linux-next/next-iwlwifi-fix-modular-legacy-build-errors.patch
+ mm-fixes/cgroup-Avoid-a-memset-by-using-vzalloc.patch
+ mm-fixes/kmemleak-remove-memset-by-using-kzalloc.patch
+ linux-2.6-block-for-2.6.38-core/linux-2.6-block-for-2.6.38-core.patch
+ tpm-fix/tpm-Autodetect-itpm-devices.patch
+ extracted-from-embed-gtt-space/0008-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
+ extracted-from-embed-gtt-space/0081-drm-nouveau-don-t-munge-in-drm_mm-internals.patch
+ extracted-from-embed-gtt-space/0082-drm-mm-track-free-areas-implicitly.patch
+ extracted-from-embed-gtt-space/0083-drm-mm-extract-node-insert-helper-functions.patch
+ extracted-from-embed-gtt-space/0084-drm-mm-add-api-for-embedding-struct-drm_mm_node.patch
+ extracted-from-embed-gtt-space/0085-drm-i915-embed-struct-drm_mm_node-into-struct-drm_i9.patch
+ extracted-from-embed-gtt-space/0086-drm-i915-kill-obj-gtt_offset.patch
+ extracted-from-embed-gtt-space/0087-drm-i915-kill-gtt_list.patch
+ extracted-from-embed-gtt-space/0088-drm-mm-add-helper-to-unwind-scan-state.patch
+ extracted-from-embed-gtt-space/0089-drm-i915-use-drm_mm_for_each_scanned_node_reverse-he.patch
+ debian/version.patch
+ debian/kernelvariables-2.6.37.patch
+ debian/doc-build-parallel.patch
+ bugfix/ia64/hardcode-arch-script-output.patch
+ bugfix/mips/disable-advansys.patch
+ bugfix/arm/disable-scsi_acard.patch
+ debian/mips-disable-werror.patch
+ bugfix/powerpc/lpar-console.patch
+ features/all/i915-autoload-without-CONFIG_DRM_I915_KMS.patch
+ debian/arch-sh4-fix-uimage-build.patch
+ bugfix/mips/mips-ide-flush-dcache.patch
+ bugfix/all/qla4xxx-Fix-build-on-some-architectures-lacking-64-bit-I-O.patch
+ bugfix/x86/Skip-looking-for-ioapic-overrides-when-ioapics-are-not-present.patch
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc1$
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc1$
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc1$
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc1$ LC_ALL=C fakeroot make -f
debian/rules.gen setup_i386_none_686 2>&1 | tee ../setup.log
make -f debian/rules.real setup-flavour ABINAME='' ARCH='i386'
COMPILER='gcc-4.4' FEATURESET='none' FLAVOUR='686'
INITRD_CMD='update-initramfs' KCONFIG='debian/config/config
debian/config/kernelarch-x86/config
debian/config/kernelarch-x86/config-arch-32
debian/config/i386/none/config.686' KERNEL_ARCH='x86'
LOCALVERSION='-686' LOCALVERSION_HEADERS='' LOCALVERSION_IMAGE='-686'
MAJOR='2.6' MODULES='True'
SOURCEVERSION='2.6.37~rc1-11~next~20101112.1~dileks.1' TYPE='plain'
UPSTREAMVERSION='2.6.37-rc1' VERSION='2.6.37'
make[1]: Entering directory `/home/sd/src/linux-2.6/linux-2.6.37-rc1'
rm -rf 'debian/build/source'
mkdir -p 'debian/build/source'
cp -al COPYING CREDITS Documentation Kbuild Kconfig MAINTAINERS
Makefile README REPORTING-BUGS arch block crypto drivers firmware fs
include init ipc kernel lib mm net samples scripts security sound
tools usr virt .gitignore .mailmap 'debian/build/source'
cd 'debian/build/source'; python
'/home/sd/src/linux-2.6/linux-2.6.37-rc1/debian/bin/patch.apply'
--overwrite-home='/home/sd/src/linux-2.6/linux-2.6.37-rc1/debian/patches'
/home/sd/src/linux-2.6/linux-2.6.37-rc1/debian/bin/patch.apply:81:
DeprecationWarning: functions overriding warnings.showwarning() must
support the 'line' argument
  warn('No %s file, assuming Debian Linux %s' % (self._file, upstream))
Warning: No version.Debian file, assuming Debian Linux 2.6.37~rc1
5 out of 11 hunks FAILED -- saving rejects to file drivers/gpu/drm/drm_mm.c.rej
Error: Patch failed
--> Try to apply base.
  (+) OK   linux-next/patch-v2.6.37-rc1-next-20101112
  (+) OK   linux-next/0001-Remove-localversion-next.patch
  (+) OK   for-linux-next/next-iwlwifi-fix-modular-legacy-build-errors.patch
  (+) OK   mm-fixes/cgroup-Avoid-a-memset-by-using-vzalloc.patch
  (+) OK   mm-fixes/kmemleak-remove-memset-by-using-kzalloc.patch
  (+) OK   linux-2.6-block-for-2.6.38-core/linux-2.6-block-for-2.6.38-core.patch
  (+) OK   tpm-fix/tpm-Autodetect-itpm-devices.patch
  (+) OK   extracted-from-embed-gtt-space/0008-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
  (+) OK   extracted-from-embed-gtt-space/0081-drm-nouveau-don-t-munge-in-drm_mm-internals.patch
  (+) FAIL extracted-from-embed-gtt-space/0082-drm-mm-track-free-areas-implicitly.patch
make[1]: *** [debian/stamps/source] Error 1
make[1]: Leaving directory `/home/sd/src/linux-2.6/linux-2.6.37-rc1'
make: *** [setup_i386_none_686_real] Error 2
sd@tbox:~/src/linux-2.6/linux-2.6.37-rc1$
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Daniel Vetter]

On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
> Hmm, I tried with your patches from ML plus missing patch and
> extracted patches from ~danvet/drm/embed-gtt-space.
> Sth. messed up....
> 
> Could be a "big.diff" is needed, *not* a chronological series.
> I will do a big.diff from 0081..0089 and apply
> 0008-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch first.
I've pushed out a for-sedat-dilek branch to my fdo repo. That one compiles
... Patches simply cherry-picked with git.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Sedat Dilek]

On Sun, Nov 14, 2010 at 7:54 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
>> Hmm, I tried with your patches from ML plus missing patch and
>> extracted patches from ~danvet/drm/embed-gtt-space.
>> Sth. messed up....
>>
>> Could be a "big.diff" is needed, *not* a chronological series.
>> I will do a big.diff from 0081..0089 and apply
>> 0008-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch first.
> I've pushed out a for-sedat-dilek branch to my fdo repo. That one compiles
> ... Patches simply cherry-picked with git.
> -Daniel
> --
> Daniel Vetter
> Mail: daniel@ffwll.ch
> Mobile: +41 (0)79 365 57 48
>

After erasing my source-dir and re-unpacking Linux-2.6.37-rc1 tarball,
I could apply the ~danvet/drm/for-sedat-dilek GIT branch.

Thanks also for the hints on IRC.

Just compiling my "big" patch-series:

$ grep OK setup_linux-next_next-20101112.1.log
  (+) OK   linux-next/patch-v2.6.37-rc1-next-20101112
  (+) OK   linux-next/0001-Remove-localversion-next.patch
  (+) OK   for-linux-next/next-iwlwifi-fix-modular-legacy-build-errors.patch
  (+) OK   none-BKL-config/drm-i810-remove-SMP-support-and-BKL.patch
  (+) OK   drm-vblank-timestamping/1-3-drm-vblank-Add-support-for-precise-vblank-timestamping.patch
  (+) OK   drm-vblank-timestamping/2-3-kms-radeon-Add-support-for-precise-vblank-timestamping.patch
  (+) OK   drm-vblank-timestamping/drm-i915-fix-assignment-obj_priv-to_intel_bo.patch
  (+) OK   drm-vblank-timestamping/3-3-kms-i915-Add-support-for-precise-vblank-timestamping.patch
  (+) OK   drm-vblank-timestamping/drm-i915-fix-error-implicit-declaration-of-function-IS_IRONLAKE.patch
  (+) OK   agd5f-pflip/0002-drm-radeon-kms-add-pageflip-ioctl-support.patch
  (+) OK   backlight-type/Backlight-Add-backlight-type-v2.patch
  (+) OK   backlight-type/radeon-Expose-backlight-class-device-for-legacy-LVDS-encoder.patch
  (+) OK   mm-fixes/cgroup-Avoid-a-memset-by-using-vzalloc.patch
  (+) OK   mm-fixes/kmemleak-remove-memset-by-using-kzalloc.patch
  (+) OK   linux-2.6-block-for-2.6.38-core/linux-2.6-block-for-2.6.38-core.patch
  (+) OK   tpm-fix/tpm-Autodetect-itpm-devices.patch
  (+) OK   danvet-embed-drm_gem_object-into-radeon_bo/1-3-drm-radeon-embed-struct-drm_gem_object.patch
  (+) OK   danvet-embed-drm_gem_object-into-radeon_bo/2-3-drm-radeon-introduce-gem_to_radeon_bo-helper.patch
  (+) OK   danvet-embed-drm_gem_object-into-radeon_bo/3-3-drm-radeon-kill-radeon_bo--gobj-pointer.patch
  (+) OK   danvet-drm-for-sedat-dilek/0001-drm-nouveau-don-t-munge-in-drm_mm-internals.patch
  (+) OK   danvet-drm-for-sedat-dilek/0002-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
  (+) OK   danvet-drm-for-sedat-dilek/0003-drm-mm-track-free-areas-implicitly.patch
  (+) OK   danvet-drm-for-sedat-dilek/0004-drm-mm-extract-node-insert-helper-functions.patch
  (+) OK   danvet-drm-for-sedat-dilek/0005-drm-mm-add-api-for-embedding-struct-drm_mm_node.patch
  (+) OK   danvet-drm-for-sedat-dilek/0006-drm-mm-add-helper-to-unwind-scan-state.patch
  (+) OK   debian/version.patch
  (+) OK   debian/kernelvariables-2.6.37.patch
  (+) OK   debian/doc-build-parallel.patch
  (+) OK   bugfix/ia64/hardcode-arch-script-output.patch
  (+) OK   bugfix/mips/disable-advansys.patch
  (+) OK   bugfix/arm/disable-scsi_acard.patch
  (+) OK   debian/mips-disable-werror.patch
  (+) OK   bugfix/powerpc/lpar-console.patch
  (+) OK   features/all/i915-autoload-without-CONFIG_DRM_I915_KMS.patch
  (+) OK   debian/arch-sh4-fix-uimage-build.patch
  (+) OK   bugfix/mips/mips-ide-flush-dcache.patch
  (+) OK   bugfix/all/qla4xxx-Fix-build-on-some-architectures-lacking-64-bit-I-O.patch
  (+) OK   bugfix/x86/Skip-looking-for-ioapic-overrides-when-ioapics-are-not-present.patch

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Daniel Vetter]

On Mon, Nov 15, 2010 at 09:40:14PM +0100, Thomas Hellstrom wrote:
> >Hence I think that drivers with extremely specific needs should roll their
> >own allocator. So I don't think we should anticipate different allocator
> >algorithms. I see driver-specific stuff more in the area of clever
> >eviction algorithms - i915 is currently at 5 lru's for gtt mapped bos, and
> >we're still adding.
> >
> >
> 
> Yes, I agree. My point was merely that one should think twice before
> embedding
> drm_mm objects in generic buffer objects intended also for drivers
> with special needs.

Ok, I see. Looks like I've slightly shot over the mark here ;-) As I've
said, I don't have any immediate plans to create havoc in ttm. And if I
start doing so, I'll do it in (hopefully) incrementally useful steps.

> Thanks,
> Thomas

Thanks, Daniel

-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Thomas Hellstrom]

On 11/15/2010 08:45 PM, Daniel Vetter wrote:
> Hi Thomas,
>
> On Mon, Nov 15, 2010 at 08:58:13AM +0100, Thomas Hellstrom wrote:
>    
>> Nice work, although I have some comments about general applicability
>> that we perhaps need to think about.
>>
>> 1) The space representation and space allocation algorithm is
>> something that is private to the aperture management system. For a
>> specialized implementation like i915 that is all fine, but Ben has
>> recently abstracted that part out of the core TTM bo implementation.
>> As an example, vmwgfx is now using kernel idas to manage aperture
>> space, and drm_mm objects for traditional VRAM space. Hence,
>> embedding drm_mm objects into ttm bos will not really be worthwile.
>> At least not for aperture space management, and TTM will need to
>> continue to "dance", both in the ida case and in the drm_mm case.
>>      
> Yep, I've looked into this and noticed the recent addition of the ida
> support. This is why I've added the "decent surgery" comment. Embedding
> the drm_mm_node still looks possible, albeit perhaps not feasible (at
> least I won't tackle this in the immediate future).
>    

Indeed, it's possible but for drivers that don't use it, it will sit unused.

>> 2) The algorithm used by drm_mm has been around for a while and has
>> seen a fair amount of changes, but nobody has yet attacked the
>> algorithm used to search for free space, which was just quickly put
>> together as an improvement on what was the old mesa range manager.
>> In moderate fragmentation situations, the performance will degrade,
>> particularly with "best match" searches. In the near future we'd
>> probably want to add something like a "hole rb tree" rather than a
>> "hole list", and a choice of algorithm for the user. With embeddable
>> objects, unless you want to waste space for unused members, you'd
>> need a separate drm_mm node subclass for each algorithm, whereas if
>> you don't embed, you only need to allocate what you need.
>>      
> First a small rant about "best match" (to get it out of the way;-)
> - "best match" is simply a misleading name: with alignment>  size
>    (at least on older hw) and mixes of unrestricted and range restricted
>    allocations (ironlake has 2G of gtt, just 256 of it mappable), which is
>    all possible with the latest experimental i915 patches, "best match" can
>    do worse than the simpler approach.
> - doing a full linear scan for every tiny state buffer/pixmap cache is
>    slow.
> At this, it serves as an excuse to not implement proper eviction support.
> </rant>
> [If you agree, I'll happily write the patch to rip it out. It just doesn't
> bother me 'cause it's only a few lines in drm_mm.c and I can ignore the
> actual users.]
>
> Now to the more useful discussion: IMHO drm_mm.c should be an allocator
> for vram/(g)tt, i.e. it needs to support:
> - a mix of large/small sizes.
> - fancy alignment constrains (new patches for drm/i915 are pushing things
>    there).
> - range-restricted allocations. I think current users only ever have one
>    (start, end) set for restricted allocations, so this might actually be
>    simplified.
> If other users don't fit into this anymore, mea culpa, they need they're
> own allocator. You've already taken this path for vmwgfx by using the ida
> allocator. And if the linear scan for the gem mmap offset allocator ever
> shows up in profiles, I think it's better served with a buddy-style
> pot-sized, pot-aligned allocator. After all, fragmentation of virtual
> address space isn't a that severe problem.
>    

I must admit I haven't done detailed benchmarking, particularly not for
cases with a _huge_ number of bo's but I'm prepared to accept the fact that
"first match" gives good enough results. For the mmap offset 
fragmentation it's
less of a problem since it should be straightforward to move bos in the 
address space with
an additional translation of the user-space offset (if ever needed).

> Hence I think that drivers with extremely specific needs should roll their
> own allocator. So I don't think we should anticipate different allocator
> algorithms. I see driver-specific stuff more in the area of clever
> eviction algorithms - i915 is currently at 5 lru's for gtt mapped bos, and
> we're still adding.
>
>
>    

Yes, I agree. My point was merely that one should think twice before 
embedding
drm_mm objects in generic buffer objects intended also for drivers with 
special needs.

> To make a long story short, I've opted to make the current code faster by
> avoiding kmalloc and spoiling fewer cache-lines with useless data. And if
> the linear scan ever shows up in profiles, we could always add some stats
> to bail out early for large allocations. Or add a tree to heuristically
> find a suitable hole (assuming worst-case waste due to alignment).
>
>    

> Thanks a lot for your input on this.
>
> Yours, Daniel
>    

Thanks,
Thomas

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Daniel Vetter]

Hi Thomas,

On Mon, Nov 15, 2010 at 08:58:13AM +0100, Thomas Hellstrom wrote:
> Nice work, although I have some comments about general applicability
> that we perhaps need to think about.
> 
> 1) The space representation and space allocation algorithm is
> something that is private to the aperture management system. For a
> specialized implementation like i915 that is all fine, but Ben has
> recently abstracted that part out of the core TTM bo implementation.
> As an example, vmwgfx is now using kernel idas to manage aperture
> space, and drm_mm objects for traditional VRAM space. Hence,
> embedding drm_mm objects into ttm bos will not really be worthwile.
> At least not for aperture space management, and TTM will need to
> continue to "dance", both in the ida case and in the drm_mm case.

Yep, I've looked into this and noticed the recent addition of the ida
support. This is why I've added the "decent surgery" comment. Embedding
the drm_mm_node still looks possible, albeit perhaps not feasible (at
least I won't tackle this in the immediate future).

> For device address space, the situation is different, though, and it
> should be possible to embed the drm_mm objects, but that brings up
> the next thing:
> 
> 2) The algorithm used by drm_mm has been around for a while and has
> seen a fair amount of changes, but nobody has yet attacked the
> algorithm used to search for free space, which was just quickly put
> together as an improvement on what was the old mesa range manager.
> In moderate fragmentation situations, the performance will degrade,
> particularly with "best match" searches. In the near future we'd
> probably want to add something like a "hole rb tree" rather than a
> "hole list", and a choice of algorithm for the user. With embeddable
> objects, unless you want to waste space for unused members, you'd
> need a separate drm_mm node subclass for each algorithm, whereas if
> you don't embed, you only need to allocate what you need.

First a small rant about "best match" (to get it out of the way;-)
- "best match" is simply a misleading name: with alignment > size
  (at least on older hw) and mixes of unrestricted and range restricted
  allocations (ironlake has 2G of gtt, just 256 of it mappable), which is
  all possible with the latest experimental i915 patches, "best match" can
  do worse than the simpler approach.
- doing a full linear scan for every tiny state buffer/pixmap cache is
  slow.
At this, it serves as an excuse to not implement proper eviction support.
</rant>
[If you agree, I'll happily write the patch to rip it out. It just doesn't
bother me 'cause it's only a few lines in drm_mm.c and I can ignore the
actual users.]

Now to the more useful discussion: IMHO drm_mm.c should be an allocator
for vram/(g)tt, i.e. it needs to support:
- a mix of large/small sizes.
- fancy alignment constrains (new patches for drm/i915 are pushing things
  there).
- range-restricted allocations. I think current users only ever have one
  (start, end) set for restricted allocations, so this might actually be
  simplified.
If other users don't fit into this anymore, mea culpa, they need they're
own allocator. You've already taken this path for vmwgfx by using the ida
allocator. And if the linear scan for the gem mmap offset allocator ever
shows up in profiles, I think it's better served with a buddy-style
pot-sized, pot-aligned allocator. After all, fragmentation of virtual
address space isn't a that severe problem.

Hence I think that drivers with extremely specific needs should roll their
own allocator. So I don't think we should anticipate different allocator
algorithms. I see driver-specific stuff more in the area of clever
eviction algorithms - i915 is currently at 5 lru's for gtt mapped bos, and
we're still adding.

Of course I've spent a bunch of brain-cycles on creating a more efficient
allocator - O(n) just doesn't look that good. Now
- it should be fast in the common case
- and not degerate into O(n) for ugly corner cases.
Which leaves us for the above allocation requirements of (u64 size, u32
alignment, bool range_restricted) with two 2d-range-trees. Now factoring
in that lru-scanning is also O(n_{gtt_mapped}) gives us a data-structure
I'm not really eager to create.

Current code seems fares rather well because the hole_stack fifo is good
at avoiding the linear scan worst-case. And as soon as we start to strash
the gtt, everything is totally snowed under by clflush overhead on i915
anyway.

To make a long story short, I've opted to make the current code faster by
avoiding kmalloc and spoiling fewer cache-lines with useless data. And if
the linear scan ever shows up in profiles, we could always add some stats
to bail out early for large allocations. Or add a tree to heuristically
find a suitable hole (assuming worst-case waste due to alignment).

Thanks a lot for your input on this.

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Sedat Dilek]

Hi Daniel,

I have tried a reduced patchset (w/o drm/i915 stuff) from [1] on a
RV250 with linux-next (next-20101115).
(See also P.S. for my full patchset)

# lspci -nnvv | grep "VGA compatible controller"
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon
RV250 [Mobility FireGL 9000] [1002:4c66] (rev 02) (prog-if 00 [VGA
controller])

Mesa is from master GIT:
commit 9cf25b3d1cd2910ae33e1faafa04629638bff0fe:
"r300g: return shader caps from Draw for SWTCL vertex shaders"

Also here I tried with Eric Anholt's OpenArena benchmark.
Seen from fps it is around 14 @ 1024x768 resolution (aprrox. same w/o
Daniel's patchset).
The only thing I see is garbage on my KDE4-desktop when benchmark ends.
Switching to a console (VT-1/VT-2) and changing back to X (default:
VT-7) makes the garbage go away.


Kind Regards,
- Sedat -

[1] http://cgit.freedesktop.org/~danvet/drm/log/?h=for-sedat-dilek

P.S.:
My full patchset looks like this - not sure if there is a correlation
with other drm/radeon patches:

$ grep OK setup_linux-next_next-20101115.1.log
  (+) OK   linux-next/patch-v2.6.37-rc1-next-20101115
  (+) OK   linux-next/0001-Remove-localversion-next.patch
  (+) OK   for-linux-next/next-iwlwifi-fix-modular-legacy-build-errors.patch
  (+) OK   none-BKL-config/drm-i810-remove-SMP-support-and-BKL.patch
  (+) OK   for-drm-radeon-testing/drm-radeon-kms-enable-writeback-on-radeon-AGP-boards.patch
  (+) OK   drm-vblank-timestamping/1-3-drm-vblank-Add-support-for-precise-vblank-timestamping.patch
  (+) OK   drm-vblank-timestamping/2-3-kms-radeon-Add-support-for-precise-vblank-timestamping.patch
  (+) OK   drm-vblank-timestamping/drm-i915-fix-assignment-obj_priv-to_intel_bo.patch
  (+) OK   drm-vblank-timestamping/3-3-kms-i915-Add-support-for-precise-vblank-timestamping.patch
  (+) OK   drm-vblank-timestamping/drm-i915-fix-error-implicit-declaration-of-function-IS_IRONLAKE.patch
  (+) OK   agd5f-pflip/0002-drm-radeon-kms-add-pageflip-ioctl-support.patch
  (+) OK   backlight-type/Backlight-Add-backlight-type-v2.patch
  (+) OK   backlight-type/radeon-Expose-backlight-class-device-for-legacy-LVDS-encoder.patch
  (+) OK   mm-fixes/cgroup-Avoid-a-memset-by-using-vzalloc.patch
  (+) OK   mm-fixes/kmemleak-remove-memset-by-using-kzalloc.patch
  (+) OK   linux-2.6-block-for-2.6.38-core/linux-2.6-block-for-2.6.38-core.patch
  (+) OK   tpm-fix/tpm-Autodetect-itpm-devices.patch
  (+) OK   danvet-drm-for-sedat-dilek/0001-drm-nouveau-don-t-munge-in-drm_mm-internals.patch
  (+) OK   danvet-drm-for-sedat-dilek/0002-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
  (+) OK   danvet-drm-for-sedat-dilek/0003-drm-mm-track-free-areas-implicitly.patch
  (+) OK   danvet-drm-for-sedat-dilek/0004-drm-mm-extract-node-insert-helper-functions.patch
  (+) OK   danvet-drm-for-sedat-dilek/0005-drm-mm-add-api-for-embedding-struct-drm_mm_node.patch
  (+) OK   danvet-drm-for-sedat-dilek/0006-drm-mm-add-helper-to-unwind-scan-state.patch
  (+) OK   debian/version.patch
  (+) OK   debian/kernelvariables-2.6.37.patch
  (+) OK   debian/doc-build-parallel.patch
  (+) OK   bugfix/ia64/hardcode-arch-script-output.patch
  (+) OK   bugfix/mips/disable-advansys.patch
  (+) OK   bugfix/arm/disable-scsi_acard.patch
  (+) OK   debian/mips-disable-werror.patch
  (+) OK   bugfix/powerpc/lpar-console.patch
  (+) OK   features/all/i915-autoload-without-CONFIG_DRM_I915_KMS.patch
  (+) OK   debian/arch-sh4-fix-uimage-build.patch
  (+) OK   bugfix/mips/mips-ide-flush-dcache.patch
  (+) OK   bugfix/all/qla4xxx-Fix-build-on-some-architectures-lacking-64-bit-I-O.patch
  (+) OK   bugfix/x86/Skip-looking-for-ioapic-overrides-when-ioapics-are-not-present.patch

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Thomas Hellstrom]

On 11/12/2010 06:36 PM, Daniel Vetter wrote:
> Hi all,
>
> This patch-set changes the algorithm in drm_mm.c to not need additional
> allocations to track free space and adds an api to make embedding struct
> drm_mm_node possible. Benefits:
>
> - If struct drm_mm_node is provided, no allocations need to be done anymore
>    in drm_mm. It looks like some decent surgery, but ttm should be able to
>    drop its preallocation dance.
> - void *priv is back, but done right ;)
> - Avoids a pointer chase when lru-scanning in i915 and saves a few bytes.
>
> As a proof of concept I've converted i915. Beware though, the drm/i915
> patches depend on my direct-gtt patches (which are actually the reason for
> this series here).
>
> Tested on my i855gm, i945gme, ironlake and agp rv570.
>
> Comments, flames, reviews highly welcome.
>    

Hi, Daniel!

Nice work, although I have some comments about general applicability 
that we perhaps need to think about.

1) The space representation and space allocation algorithm is something 
that is private to the aperture management system. For a specialized 
implementation like i915 that is all fine, but Ben has recently 
abstracted that part out of the core TTM bo implementation. As an 
example, vmwgfx is now using kernel idas to manage aperture space, and 
drm_mm objects for traditional VRAM space. Hence, embedding drm_mm 
objects into ttm bos will not really be worthwile. At least not for 
aperture space management, and TTM will need to continue to "dance", 
both in the ida case and in the drm_mm case. For device address space, 
the situation is different, though, and it should be possible to embed 
the drm_mm objects, but that brings up the next thing:

2) The algorithm used by drm_mm has been around for a while and has seen 
a fair amount of changes, but nobody has yet attacked the algorithm used 
to search for free space, which was just quickly put together as an 
improvement on what was the old mesa range manager. In moderate 
fragmentation situations, the performance will degrade, particularly 
with "best match" searches. In the near future we'd probably want to add 
something like a "hole rb tree" rather than a "hole list", and a choice 
of algorithm for the user. With embeddable objects, unless you want to 
waste space for unused members, you'd need a separate drm_mm node 
subclass for each algorithm, whereas if you don't embed, you only need 
to allocate what you need.

/Thomas




> Please consider merging the core drm parts (and the nouveau prep patch) for
> -next (the i915 patches need coordination with Chris Wilson, they're rather
> invasive).
>
> Thanks, Daniel
>
> Daniel Vetter (9):
>    drm/nouveau: don't munge in drm_mm internals
>    drm: mm: track free areas implicitly
>    drm: mm: extract node insert helper functions
>    drm: mm: add api for embedding struct drm_mm_node
>    drm/i915: embed struct drm_mm_node into struct drm_i915_gem_object
>    drm/i915: kill obj->gtt_offset
>    drm/i915: kill gtt_list
>    drm: mm: add helper to unwind scan state
>    drm/i915: use drm_mm_for_each_scanned_node_reverse helper
>
>   drivers/gpu/drm/drm_mm.c                 |  570 ++++++++++++++++-------------
>   drivers/gpu/drm/i915/i915_debugfs.c      |   22 +-
>   drivers/gpu/drm/i915/i915_drv.h          |   13 +-
>   drivers/gpu/drm/i915/i915_gem.c          |  173 ++++-----
>   drivers/gpu/drm/i915/i915_gem_debug.c    |   10 +-
>   drivers/gpu/drm/i915/i915_gem_evict.c    |   37 +-
>   drivers/gpu/drm/i915/i915_gem_gtt.c      |   14 +-
>   drivers/gpu/drm/i915/i915_gem_tiling.c   |    6 +-
>   drivers/gpu/drm/i915/i915_irq.c          |   34 +-
>   drivers/gpu/drm/i915/intel_display.c     |   26 +-
>   drivers/gpu/drm/i915/intel_fb.c          |    6 +-
>   drivers/gpu/drm/i915/intel_overlay.c     |   14 +-
>   drivers/gpu/drm/i915/intel_ringbuffer.c  |   10 +-
>   drivers/gpu/drm/nouveau/nouveau_object.c |    2 +-
>   drivers/gpu/drm/nouveau/nv50_instmem.c   |    2 +-
>   include/drm/drm_mm.h                     |   49 ++-
>   16 files changed, 525 insertions(+), 463 deletions(-)
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>    

Re: [PATCH 0/9] make struct drm_mm_node embeddable

[Chris Wilson]

On Fri, 12 Nov 2010 18:36:32 +0100, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Hi all,
> 
> This patch-set changes the algorithm in drm_mm.c to not need additional
> allocations to track free space and adds an api to make embedding struct
> drm_mm_node possible.

I like the end result for i915 in that it couples the bo much more tightly
with their allocations; to manage the bo is to manage those allocations.
This aligns well with my review of the memory management for i915.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 0/9] make struct drm_mm_node embeddable

[Daniel Vetter]

Hi all,

This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:

- If struct drm_mm_node is provided, no allocations need to be done anymore
  in drm_mm. It looks like some decent surgery, but ttm should be able to
  drop its preallocation dance.
- void *priv is back, but done right ;)
- Avoids a pointer chase when lru-scanning in i915 and saves a few bytes.

As a proof of concept I've converted i915. Beware though, the drm/i915
patches depend on my direct-gtt patches (which are actually the reason for
this series here).

Tested on my i855gm, i945gme, ironlake and agp rv570.

Comments, flames, reviews highly welcome.

Please consider merging the core drm parts (and the nouveau prep patch) for
-next (the i915 patches need coordination with Chris Wilson, they're rather
invasive).

Thanks, Daniel

Daniel Vetter (9):
  drm/nouveau: don't munge in drm_mm internals
  drm: mm: track free areas implicitly
  drm: mm: extract node insert helper functions
  drm: mm: add api for embedding struct drm_mm_node
  drm/i915: embed struct drm_mm_node into struct drm_i915_gem_object
  drm/i915: kill obj->gtt_offset
  drm/i915: kill gtt_list
  drm: mm: add helper to unwind scan state
  drm/i915: use drm_mm_for_each_scanned_node_reverse helper

 drivers/gpu/drm/drm_mm.c                 |  570 ++++++++++++++++-------------
 drivers/gpu/drm/i915/i915_debugfs.c      |   22 +-
 drivers/gpu/drm/i915/i915_drv.h          |   13 +-
 drivers/gpu/drm/i915/i915_gem.c          |  173 ++++-----
 drivers/gpu/drm/i915/i915_gem_debug.c    |   10 +-
 drivers/gpu/drm/i915/i915_gem_evict.c    |   37 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c      |   14 +-
 drivers/gpu/drm/i915/i915_gem_tiling.c   |    6 +-
 drivers/gpu/drm/i915/i915_irq.c          |   34 +-
 drivers/gpu/drm/i915/intel_display.c     |   26 +-
 drivers/gpu/drm/i915/intel_fb.c          |    6 +-
 drivers/gpu/drm/i915/intel_overlay.c     |   14 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c  |   10 +-
 drivers/gpu/drm/nouveau/nouveau_object.c |    2 +-
 drivers/gpu/drm/nouveau/nv50_instmem.c   |    2 +-
 include/drm/drm_mm.h                     |   49 ++-
 16 files changed, 525 insertions(+), 463 deletions(-)