On Mon, May 14, 2018 at 07:35:03AM -0300, Mauro Carvalho Chehab wrote:
> Hi Fabien,
>
> Em Mon, 14 May 2018 08:00:37 +
> Fabien DESSENNE escreveu:
>
> > On 07/05/18 17:19, Mauro Carvalho Chehab wrote:
> > > Em Mon, 07 May 2018 16:26:08 +0300
> > > Laurent Pinchart escreveu:
> > >
> > >> H
Hi Laurent,
Em Tue, 15 May 2018 11:27:44 +0300
Laurent Pinchart escreveu:
> Hello,
>
> On Tuesday, 15 May 2018 10:30:28 EEST Fabien DESSENNE wrote:
> > On 14/05/18 12:39, Mauro Carvalho Chehab wrote:
> > > Em Mon, 14 May 2018 07:35:03 -0300 Mauro Carvalho Chehab escreveu:
> > >> Em Mon, 14
Hello,
On Tuesday, 15 May 2018 10:30:28 EEST Fabien DESSENNE wrote:
> On 14/05/18 12:39, Mauro Carvalho Chehab wrote:
> > Em Mon, 14 May 2018 07:35:03 -0300 Mauro Carvalho Chehab escreveu:
> >> Em Mon, 14 May 2018 08:00:37 + Fabien DESSENNE escreveu:
> >>> On 07/05/18 17:19, Mauro Carvalho Che
On 14/05/18 12:39, Mauro Carvalho Chehab wrote:
> Em Mon, 14 May 2018 07:35:03 -0300
> Mauro Carvalho Chehab escreveu:
>
>> Hi Fabien,
>>
>> Em Mon, 14 May 2018 08:00:37 +
>> Fabien DESSENNE escreveu:
>>
>>> On 07/05/18 17:19, Mauro Carvalho Chehab wrote:
Em Mon, 07 May 2018 16:26:08 +
Em Mon, 14 May 2018 07:35:03 -0300
Mauro Carvalho Chehab escreveu:
> Hi Fabien,
>
> Em Mon, 14 May 2018 08:00:37 +
> Fabien DESSENNE escreveu:
>
> > On 07/05/18 17:19, Mauro Carvalho Chehab wrote:
> > > Em Mon, 07 May 2018 16:26:08 +0300
> > > Laurent Pinchart escreveu:
> > >
> > >> Hi
Hi Fabien,
Em Mon, 14 May 2018 08:00:37 +
Fabien DESSENNE escreveu:
> On 07/05/18 17:19, Mauro Carvalho Chehab wrote:
> > Em Mon, 07 May 2018 16:26:08 +0300
> > Laurent Pinchart escreveu:
> >
> >> Hi Mauro,
> >>
> >> On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:
> >
On 07/05/18 17:19, Mauro Carvalho Chehab wrote:
> Em Mon, 07 May 2018 16:26:08 +0300
> Laurent Pinchart escreveu:
>
>> Hi Mauro,
>>
>> On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:
>>> There was a recent discussion about the use/abuse of GFP_DMA flag when
>>> allocating memo
Dear Mauro
> -Original Message-
>
> There was a recent discussion about the use/abuse of GFP_DMA flag when
> allocating memories at LSF/MM 2018 (see Luis notes enclosed).
>
> The idea seems to be to remove it, using CMA instead. Before doing that,
> better to check if what we have on med
Em Mon, 07 May 2018 16:26:08 +0300
Laurent Pinchart escreveu:
> Hi Mauro,
>
> On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:
> > There was a recent discussion about the use/abuse of GFP_DMA flag when
> > allocating memories at LSF/MM 2018 (see Luis notes enclosed).
> >
> > T
Hi Mauro,
On Saturday, 5 May 2018 19:08:15 EEST Mauro Carvalho Chehab wrote:
> There was a recent discussion about the use/abuse of GFP_DMA flag when
> allocating memories at LSF/MM 2018 (see Luis notes enclosed).
>
> The idea seems to be to remove it, using CMA instead. Before doing that,
> bett
There was a recent discussion about the use/abuse of GFP_DMA flag when
allocating memories at LSF/MM 2018 (see Luis notes enclosed).
The idea seems to be to remove it, using CMA instead. Before doing that,
better to check if what we have on media is are valid use cases for it, or
if it is there ju
On Thu, May 03, 2018 at 02:03:38PM +0200, Michal Hocko wrote:
> On Sat 28-04-18 19:10:47, Matthew Wilcox wrote:
> > Another way we could approach this is to get rid of ZONE_DMA. Make GFP_DMA
> > a flag which doesn't map to a zone. Rather, it redirects to a separate
> > allocator. At boot, we hand a
On Sat 28-04-18 19:10:47, Matthew Wilcox wrote:
> Another way we could approach this is to get rid of ZONE_DMA. Make GFP_DMA
> a flag which doesn't map to a zone. Rather, it redirects to a separate
> allocator. At boot, we hand all memory under 16MB to the DMA allocator. The
> DMA allocator can hav
Hi Luis,
On Thu, Apr 26, 2018 at 11:54 PM, Luis R. Rodriguez wrote:
> x86 implicit and explicit ZONE_DMA users
> -
>
> We list below all x86 implicit and explicit ZONE_DMA users.
>
> # Explicit x86 users of GFP_DMA or __GFP_DMA
>
> * drivers/iio/common/ss
Here are some improved results, also taking into account the pci
functions.
julia
too small: drivers/gpu/drm/i915/i915_drv.c:1138: 30
too small: drivers/hwtracing/coresight/coresight-tmc.c:335: 0
too small: drivers/media/pci/sta2x11/sta2x11_vip.c:859: 29
too small: drivers/media/pci/sta2x11/sta2x
On Sat, Apr 28, 2018 at 09:46:52PM +0200, Julia Lawall wrote:
> FWIW, here is my semantic patch and the output - it reports on things that
> appear to be too small and things that it doesn't know about.
>
> What are the relevant pci wrappers? I didn't find them.
Basically all of the functions in
On Sat, 28 Apr 2018, Luis R. Rodriguez wrote:
> On Sat, Apr 28, 2018 at 01:42:21AM -0700, Christoph Hellwig wrote:
> > On Fri, Apr 27, 2018 at 04:14:56PM +, Luis R. Rodriguez wrote:
> > > Do we have a list of users for x86 with a small DMA mask?
> > > Or, given that I'm not aware of a tool t
On Sat, Apr 28, 2018 at 01:42:21AM -0700, Christoph Hellwig wrote:
> On Fri, Apr 27, 2018 at 04:14:56PM +, Luis R. Rodriguez wrote:
> > Do we have a list of users for x86 with a small DMA mask?
> > Or, given that I'm not aware of a tool to be able to look
> > for this in an easy way, would it b
On Fri, Apr 27, 2018 at 04:14:56PM +, Luis R. Rodriguez wrote:
> But curious, on a standard qemu x86_x64 KVM guest, which of the
> drivers do we know for certain *are* being used from the ones
> listed?
On a KVM guest probably none. But not all the world is relatively
sane and standardized VM
On Fri, Apr 27, 2018 at 11:36:23AM -0500, Christopher Lameter wrote:
> On Fri, 27 Apr 2018, Matthew Wilcox wrote:
>
> > Some devices have incredibly bogus hardware like 28 bit addressing
> > or 39 bit addressing. We don't have a good way to allocate memory by
> > physical address other than than
On Fri, Apr 27, 2018 at 11:07:07AM -0500, Christopher Lameter wrote:
> Well it looks like what we are using it for is to force allocation from
> low physical memory if we fail to obtain proper memory through a normal
> channel. The use of ZONE_DMA is only there for emergency purposes.
> I think we
On Fri, Apr 27, 2018 at 09:18:43AM +0200, Michal Hocko wrote:
> > On Thu, Apr 26, 2018 at 09:54:06PM +, Luis R. Rodriguez wrote:
> > > In practice if you don't have a floppy device on x86, you don't need
> > > ZONE_DMA,
> >
> > I call BS on that, and you actually explain later why it it BS du
On Fri 27-04-18 11:07:07, Cristopher Lameter wrote:
> On Fri, 27 Apr 2018, Michal Hocko wrote:
>
> > On Thu 26-04-18 22:35:56, Christoph Hellwig wrote:
> > > On Thu, Apr 26, 2018 at 09:54:06PM +, Luis R. Rodriguez wrote:
> > > > In practice if you don't have a floppy device on x86, you don't n
On Fri, 27 Apr 2018, Matthew Wilcox wrote:
> Some devices have incredibly bogus hardware like 28 bit addressing
> or 39 bit addressing. We don't have a good way to allocate memory by
> physical address other than than saying "GFP_DMA for anything less than
> 32, GFP_DMA32 (or GFP_KERNEL on 32-bit
On Fri, Apr 27, 2018 at 04:14:56PM +, Luis R. Rodriguez wrote:
> > Not really. We have unchecked_isa_dma to support about 4 drivers,
>
> Ah very neat:
>
> * CONFIG_CHR_DEV_OSST - "SCSI OnStream SC-x0 tape support"
That's an upper level driver, like cdrom, disk and regular tapes.
> * CO
On Fri, Apr 27, 2018 at 11:07:07AM -0500, Christopher Lameter wrote:
> Well it looks like what we are using it for is to force allocation from
> low physical memory if we fail to obtain proper memory through a normal
> channel. The use of ZONE_DMA is only there for emergency purposes.
> I think we
On Thu, Apr 26, 2018 at 10:35:56PM -0700, Christoph Hellwig wrote:
> On Thu, Apr 26, 2018 at 09:54:06PM +, Luis R. Rodriguez wrote:
> > In practice if you don't have a floppy device on x86, you don't need
> > ZONE_DMA,
>
> I call BS on that,
I did not explain though that it was not me who c
On Fri, 27 Apr 2018, Michal Hocko wrote:
> On Thu 26-04-18 22:35:56, Christoph Hellwig wrote:
> > On Thu, Apr 26, 2018 at 09:54:06PM +, Luis R. Rodriguez wrote:
> > > In practice if you don't have a floppy device on x86, you don't need
> > > ZONE_DMA,
> >
> > I call BS on that, and you actual
On Thu 26-04-18 22:35:56, Christoph Hellwig wrote:
> On Thu, Apr 26, 2018 at 09:54:06PM +, Luis R. Rodriguez wrote:
> > In practice if you don't have a floppy device on x86, you don't need
> > ZONE_DMA,
>
> I call BS on that, and you actually explain later why it it BS due
> to some drivers u
On Thu, Apr 26, 2018 at 09:54:06PM +, Luis R. Rodriguez wrote:
> In practice if you don't have a floppy device on x86, you don't need ZONE_DMA,
I call BS on that, and you actually explain later why it it BS due
to some drivers using it more explicitly. But even more importantly
we have plenty
On Thu, 2018-04-26 at 21:54 +, Luis R. Rodriguez wrote:
> Below are my notes on the ZONE_DMA discussion at LSF/MM 2018. There
> were some
> earlier discussion prior to my arrival to the session about moving
> around
> ZOME_DMA around, if someone has notes on that please share too :)
We took no
Below are my notes on the ZONE_DMA discussion at LSF/MM 2018. There were some
earlier discussion prior to my arrival to the session about moving around
ZOME_DMA around, if someone has notes on that please share too :)
PS. I'm not subscribed to linux-mm
Luis
Determining you don't need to suppor
As suggested by Jessica, I've been actively working on kmod, so
might as well reflect its maintained status.
Changes are expected to go through akpm's tree.
Cc: Jessica Yu
Suggested-by: Jessica Yu
Signed-off-by: Luis R. Rodriguez
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
d
We poke at proc sysctl enough that really we should declare it
maintained. We'll just be Cc'd and sending updates / ACK'ing
changes through akpm's tree.
Acked-by: Kees Cook
Signed-off-by: Luis R. Rodriguez
---
MAINTAINERS | 11 +++
1 file changed, 11 insertions(+)
diff --git a/MAINTAIN
Greetings,
I've just came across that stuff on the web and completely fell in love with
it! You've got to see that! Here is the link
<http://unique.nosharia.ca/e3mfj>
See you around, Pavel Machek
--
Dear my love Please pardon me if i busted into you in a wrong way but i
will like to say the truth in my heart that
I just read through your profile today and i sincerely like you and i
would
like to have a good relationship with you and,
I will like to know you more better as I am
contact me at (mirianandr...@yahoo.in)
My dearest
How are you today and your family i hope all is well with you
I am called Mirian i saw your profile today (facebook) and found you worthy to
be mine as some one whom i can lay on his airms as long as love is concern,
caring and teassing you all the
Hello my love,
My name is, i come across and read through your profile today and i became
interested in you,i will also like to know you the more,and i want you to send
an e-mail to my e-mail address so i can give you my picture for you to know
whom i am and for the both of us to know each other
In general we offer Personal Loans, home loans, car loans, hotel loans,
commercial loans, construction loans, start working capital loans, business
loans and bad credit loans, e.t.c, at lower interest rate.
We offer the right solution to your financial needs. We stand apart from other
lenders b
On Thu, Jul 05, 2007 at 01:34:20AM +0400, Alexey Dobriyan wrote:
> 1) Drop __KERNEL__ out of profile.h. It contains only internal kernel stuff
> and
>not in exported headers list
> 2) Put profile.c under CONFIG_PROFILING. You enabled profiling in config, you
>will get it. Removes condition
On 08/07/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
On Thu, Jul 05, 2007 at 01:50:27AM +0200, Jesper Juhl wrote:
> On 04/07/07, Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
>> 1) Drop __KERNEL__ out of profile.h. It contains only internal kernel
>> stuff and
>>not in exported headers list
>
> E
On Thu, Jul 05, 2007 at 01:50:27AM +0200, Jesper Juhl wrote:
> On 04/07/07, Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
>> 1) Drop __KERNEL__ out of profile.h. It contains only internal kernel
>> stuff and
>>not in exported headers list
>
> Even if it's not in the list of exported headers, does
On Thu, Jul 05, 2007 at 01:50:27AM +0200, Jesper Juhl wrote:
> One tiny comment below.
> >+#define prof_on 0
> >+static inline void profile_init(void)
> >+{
> >+}
>
> Just to be pedantic; don't we want a blank line between functions
> here, even if they are empty?
Dunno, it's boilerplate code, no
On Thu, 5 Jul 2007, Denis Vlasenko wrote:
> On Thursday 05 July 2007 01:50, Jesper Juhl wrote:
> > > Removes conditional branch from schedule(). Code savings on my
> > >usual config:
> > >
> > >textdata bss dec hex filename
> > > 2921871 179895 180224 3281
On Thursday 05 July 2007 01:50, Jesper Juhl wrote:
> > Removes conditional branch from schedule(). Code savings on my
> >usual config:
> >
> >textdata bss dec hex filename
> > 2921871 179895 180224 3281990 321446 vmlinux before
> > 2920141
On 04/07/07, Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
1) Drop __KERNEL__ out of profile.h. It contains only internal kernel stuff and
not in exported headers list
Even if it's not in the list of exported headers, does it really hurt
to retain that extra safeguard?
2) Put profile.c under
Alexey Dobriyan <[EMAIL PROTECTED]> writes:
> 2) Put profile.c under CONFIG_PROFILING. You enabled profiling in config, you
>will get it. Removes conditional branch from schedule(). Code savings on my
>usual config:
>
> textdata bss dec hex filename
> 292187
1) Drop __KERNEL__ out of profile.h. It contains only internal kernel stuff and
not in exported headers list
2) Put profile.c under CONFIG_PROFILING. You enabled profiling in config, you
will get it. Removes conditional branch from schedule(). Code savings on my
usual config:
t
Fixed problems so we can build with gcc-4.0.1
Signed-off-by: Peter Schaefer-Hutter <[EMAIL PROTECTED]>
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
commit dcc63579f883d388c5b4f69c4adc82423cab1de2
tree f856b999bdc0182e6299ecd4432380af0ac0
parent 1de80554bcae877dce3b6d878053eb092ef65c72
au
56 matches
Mail list logo
