Good day,
My name is Jim Zheng, head of the purchasing department at Asia
Chowtime .
After lots of research from our research department, we concluded
that you are a reliable source to import from Asia, I will need
you to verify some information for me, which is as below:
1. Do you accept par
Dear devel
I'm a procurement manager with ASDA Group (the owners of ASDA
Stores) and your company product has caught our interest.
Therefore, we request you send
list and prices of your hot selling items (products) for our
evaluation/pick.
Soon as we receive your reply, we shall send you our c
s, create new partnerships with companies dealing
with different kinds of goods globally.
Your company's products are of interest to our market as we have
an amazing market for your products.Provide us your current
catalog through email to review more. We hope to be able to order
with y
Dear driverdev-devel
We are interested in having some of your hot selling product in
our stores and outlets spread all over United Kingdom, Northern
Island and Africa. ASDA Stores Limited is one of the highest-
ranking Wholesale & Retail outlets in the United Kingdom.
We shall furnish our de
On Sat, Feb 20, 2021 at 05:56:47PM +0530, karthik alapati wrote:
> fix sparse byte-order warnings by converting host byte-order
> types to le32 types
>
> Signed-off-by: karthik alapati
This is a v2 patch...
regards,
dan carpenter
___
d
fix sparse type warning by converting __le32 types
to host byte-order types before comparison
Signed-off-by: karthik alapati
---
drivers/staging/wimax/i2400m/fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wimax/i2400m/fw.c
b/drivers/staging/wimax
fix sparse byte-order warnings by converting host byte-order
type to __le16 byte-order types before assigning to hdr.length
Signed-off-by: karthik alapati
---
drivers/staging/wimax/i2400m/op-rfkill.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wimax
fix sparse type warning by converting __le32 types
to host byte-order types before comparison
Signed-off-by: karthik alapati
---
drivers/staging/wimax/i2400m/fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wimax/i2400m/fw.c
b/drivers/staging/wimax
fix sparse byte-order warnings by converting host byte-order
type to __le16 byte-order types before assigning to hdr.length
Signed-off-by: karthik alapati
---
drivers/staging/wimax/i2400m/op-rfkill.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wimax
On Sat, Feb 20, 2021 at 06:22:31PM +0530, karthik alapati wrote:
> fix sparse type warning by converting le32 types to
> host byte-order types before comparison
>
> Signed-off-by: karthik alapati
> ---
> drivers/staging/wimax/i2400m/fw.c | 2 +-
> 1 file changed, 1 ins
fix sparse type warning by converting le32 types to
host byte-order types before comparison
Signed-off-by: karthik alapati
---
drivers/staging/wimax/i2400m/fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wimax/i2400m/fw.c
b/drivers/staging/wimax/i2400m
fix sparse type warning by converting le32 types to
host byte-order types before comparison
Signed-off-by: karthek
---
drivers/staging/wimax/i2400m/fw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wimax/i2400m/fw.c
b/drivers/staging/wimax/i2400m/fw.c
fix sparse byte-order warnings by converting host byte-order
types to le32 types
Signed-off-by: karthik alapati
---
drivers/staging/wimax/i2400m/op-rfkill.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wimax/i2400m/op-rfkill.c
b/drivers/staging/wimax
fix sparse byte-order warnings by converting host byte-order
types to le32 types
Signed-off-by: karthek
---
drivers/staging/wimax/i2400m/op-rfkill.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wimax/i2400m/op-rfkill.c
b/drivers/staging/wimax/i2400m/op
On Fri, Feb 19, 2021 at 05:51:59AM +0530, karthik alapati wrote:
> convert le32 types to host byte-order types before
> comparison
>
Already fixed. Please work against staging-next or linux-next.
regards,
dan carpenter
___
devel mailin
On Fri, Feb 19, 2021 at 06:00:47AM +0530, karthik alapati wrote:
> convert le32 types to host byte-order types before
> comparison
That says what you did, but not _why_ you did it. Please fix up and
resend.
thanks,
greg k-h
___
devel mailing l
convert le32 types to host byte-order types before
comparison
Signed-off-by: karthik alapati
---
i wonder how these could be false-positives
drivers/staging/wimax/i2400m/fw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wimax/i2400m/fw.c
b/drivers
convert le32 types to host byte-order types before
comparison
Signed-off-by: karthik alapati
---
i wonder how these could be false-positives
drivers/staging/wimax/i2400m/fw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wimax/i2400m/fw.c
b/drivers
On Fri, Feb 12, 2021 at 03:43:10PM +0100, Greg KH wrote:
> On Fri, Feb 12, 2021 at 08:00:25PM +0530, Anirudh Rayabharam wrote:
> > On Thu, Feb 11, 2021 at 09:35:27PM +0100, Greg KH wrote:
> > > On Fri, Feb 12, 2021 at 01:59:08AM +0530, Anirudh Rayabharam wrote:
> > &
Fix sparse byte-order warnings in the i2400m_bm_cmd_prepare()
function:
wimax/i2400m/fw.c:194:36: warning: restricted __le32 degrades to integer
wimax/i2400m/fw.c:195:34: warning: invalid assignment: +=
wimax/i2400m/fw.c:195:34:left side has type unsigned int
wimax/i2400m/fw.c:195:34
On Fri, Feb 12, 2021 at 08:00:25PM +0530, Anirudh Rayabharam wrote:
> On Thu, Feb 11, 2021 at 09:35:27PM +0100, Greg KH wrote:
> > On Fri, Feb 12, 2021 at 01:59:08AM +0530, Anirudh Rayabharam wrote:
> > > Fix sparse byte-order warnings in the i2400m_bm_cmd_prepar
On Thu, Feb 11, 2021 at 09:35:27PM +0100, Greg KH wrote:
> On Fri, Feb 12, 2021 at 01:59:08AM +0530, Anirudh Rayabharam wrote:
> > Fix sparse byte-order warnings in the i2400m_bm_cmd_prepare()
> > function:
> >
> > wimax/i2400m/fw.c:194:36: warning: restricted __le32 de
On Fri, Feb 12, 2021 at 01:59:08AM +0530, Anirudh Rayabharam wrote:
> Fix sparse byte-order warnings in the i2400m_bm_cmd_prepare()
> function:
>
> wimax/i2400m/fw.c:194:36: warning: restricted __le32 degrades to integer
> wimax/i2400m/fw.c:195:34: warning: invalid assignment: +=
Fix sparse byte-order warnings in the i2400m_bm_cmd_prepare()
function:
wimax/i2400m/fw.c:194:36: warning: restricted __le32 degrades to integer
wimax/i2400m/fw.c:195:34: warning: invalid assignment: +=
wimax/i2400m/fw.c:195:34:left side has type unsigned int
wimax/i2400m/fw.c:195:34
24.12.2020 09:28, Viresh Kumar пишет:
> On 23-12-20, 23:36, Dmitry Osipenko wrote:
>> 23.12.2020 07:34, Viresh Kumar пишет:
>>> On 22-12-20, 22:19, Dmitry Osipenko wrote:
22.12.2020 12:12, Viresh Kumar пишет:
> rate will be 0 for both the OPPs here if rate_not_available is true and
>
On 23-12-20, 23:36, Dmitry Osipenko wrote:
> 23.12.2020 07:34, Viresh Kumar пишет:
> > On 22-12-20, 22:19, Dmitry Osipenko wrote:
> >> 22.12.2020 12:12, Viresh Kumar пишет:
> >>> rate will be 0 for both the OPPs here if rate_not_available is true and
> >>> so this
> >>> change shouldn't be require
23.12.2020 07:34, Viresh Kumar пишет:
> On 22-12-20, 22:19, Dmitry Osipenko wrote:
>> 22.12.2020 12:12, Viresh Kumar пишет:
>>> On 17-12-20, 21:06, Dmitry Osipenko wrote:
>>>> Fix adding OPP entries in a wrong (opposite) order if OPP rate is
>>>> unav
On 22-12-20, 22:19, Dmitry Osipenko wrote:
> 22.12.2020 12:12, Viresh Kumar пишет:
> > On 17-12-20, 21:06, Dmitry Osipenko wrote:
> >> Fix adding OPP entries in a wrong (opposite) order if OPP rate is
> >> unavailable. The OPP comparison is erroneously skipped if OPP
22.12.2020 12:12, Viresh Kumar пишет:
> On 17-12-20, 21:06, Dmitry Osipenko wrote:
>> Fix adding OPP entries in a wrong (opposite) order if OPP rate is
>> unavailable. The OPP comparison is erroneously skipped if OPP rate is
>> missing, thus OPPs are left unsorted.
>&g
On 17-12-20, 21:06, Dmitry Osipenko wrote:
> Fix adding OPP entries in a wrong (opposite) order if OPP rate is
> unavailable. The OPP comparison is erroneously skipped if OPP rate is
> missing, thus OPPs are left unsorted.
>
> Signed-off-by: Dmitry Osipenko
> ---
> dr
Fix adding OPP entries in a wrong (opposite) order if OPP rate is
unavailable. The OPP comparison is erroneously skipped if OPP rate is
missing, thus OPPs are left unsorted.
Signed-off-by: Dmitry Osipenko
---
drivers/opp/core.c | 23 ---
drivers/opp/opp.h | 2 +-
2 files
Organize properties order in dt-bindings to move it out of staging.
On top: compatible, reg and interrupts.
Then alphabetical order, then properties starting with '#'.
Signed-off-by: Helen Koike
Acked-by: Rob Herring
Reviewed-by: Tomasz Figa
---
.../bindings/media/rockchip
Organize properties order in dt-bindings to move it out of staging.
On top: compatible, reg and interrupts.
Then alphabetical order, then properties starting with '#'.
Signed-off-by: Helen Koike
Acked-by: Rob Herring
---
V5:
- s/binbings/bindings
V2:
- this is a new patch in
Em Sat, 18 Jul 2020 07:05:54 +0200
Mauro Carvalho Chehab escreveu:
> From: Jonas Karlman
>
> The Rockchip Video Decoder driver is expecting that the values in a
> scaling list are in zig-zag order and applies the inverse scanning process
> to get the values in matrix ord
From: Jonas Karlman
The Rockchip Video Decoder driver is expecting that the values in a
scaling list are in zig-zag order and applies the inverse scanning process
to get the values in matrix order.
Commit 0b0393d59eb4 ("media: uapi: h264: clarify expected
scaling_list_4x4/8x8 order")
On Thu, Jul 2, 2020 at 1:13 PM Helen Koike wrote:
>
> Organize properties order in dt-binbings to move it out of staging.
typo
>
> On top: compatible, reg and interrupts.
> Then alphabetical order, then properties starting with '#'.
>
> Signed-off-by: Helen Koike
Organize properties order in dt-binbings to move it out of staging.
On top: compatible, reg and interrupts.
Then alphabetical order, then properties starting with '#'.
Signed-off-by: Helen Koike
---
V2:
- this is a new patch in the series
---
.../bindings/media/rockchip
Organize properties order in dt-binbings to move it out of staging.
On top: compatible, reg and interrupts.
Then alphabetical order, then properties starting with '#'.
Signed-off-by: Helen Koike
---
V3: none
V2:
- this is a new patch in the series
---
.../bindings/media/rockchip
This patch swaps the arguments of function get_stream_frame_size to
have the struct device as first parameter.
Signed-off-by: Christian Gromm
Reported-by: Dan Carpenter
---
drivers/staging/most/usb/usb.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/sta
On Fri, May 15, 2020 at 03:48:59PM +0200, Greg Kroah-Hartman wrote:
I still fail to understand the need for this patch at all. It doesn't
clean anything up, nor change anything. There is no rule that this has
to be in one order or the other, and in fact, I like the order that the
On Wed, May 13, 2020 at 09:15:51PM +0200, Matej Dujava wrote:
> This patch will add indentation to multiline variable and put
> obj-$(CONFIG_X) at the beginning of the file. This order of variables is
> used in other drives, so this will make vt665x Makefiles fit into the
This patch will add indentation to multiline variable and put
obj-$(CONFIG_X) at the beginning of the file. This order of variables is
used in other drives, so this will make vt665x Makefiles fit into the
pattern.
Indentation is fixed in vt6655/Makefile.
Order of variable declaration is changed
On Sun, May 10, 2020 at 12:13:35PM +0200, Matej Dujava wrote:
> This patch will add indentation to multiline variable and put obj-$(CONFIG_X)
> at the begining of the file.
Why change the order? What does that fix? Why do this? You say what
you do here, but not why. And without that, I
From: Jérôme Pouiller
The field packet_id is not interpreted by the device. It is only used as
identifier for the device answer. So it is not necessary to declare it
little endian. It fixes some warnings raised by Sparse without
complexifying the code.
Signed-off-by: Jérôme Pouiller
---
driver
From: Jérôme Pouiller
The field wakeup_period_max from struct hif_mib_beacon_wake_up_period is
a u8. So, assigning it a __le16 produces a nasty bug on big-endian
architectures.
Signed-off-by: Jérôme Pouiller
---
drivers/staging/wfx/hif_tx_mib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
From: Jérôme Pouiller
The field packet_id is not interpreted by the device. It is only used as
identifier for the device answer. So it is not necessary to declare it
little endian. It fixes some warnings raised by Sparse without
complexifying the code.
Signed-off-by: Jérôme Pouiller
---
driver
From: Jérôme Pouiller
The field wakeup_period_max from struct hif_mib_beacon_wake_up_period is
a u8. So, assigning it a __le16 produces a nasty bug on big-endian
architectures.
Signed-off-by: Jérôme Pouiller
---
drivers/staging/wfx/hif_tx_mib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
This patch will add indentation to multiline variable and put obj-$(CONFIG_X)
at the begining of the file.
Signed-off-by: Matej Dujava
---
drivers/staging/vt6655/Makefile | 24
drivers/staging/vt6656/Makefile | 4 ++--
2 files changed, 14 insertions(+), 14 deletions(-)
Organize properties order in dt-binbings to move it out of staging.
On top: compatible, reg and interrupts.
Then alphabetical order, then properties starting with '#'.
Suggested-by: Johan Jonker
Signed-off-by: Helen Koike
---
V2:
- this is a new patch in the series
---
.../bind
Hello Dear,
We are interested in purchasing your products and we sincerely hope to
establish a long-term business relation with your esteemed company.
Please kindly provide us your latest catalog. Also:
· Inform us about your minimum order quantity
· Payment terms
Luma and chroma qtables need to be written into two 16-register blocks,
each table consisting of 64 bytes total. The blocks are contiguous and
start at offset 0 for luma and at offset 0x40 for chroma.
The seemingly innocent optimization of writing the two blocks using one
loop causes side effects
The quantization tables as defined in the file (luma_q_table,
chroma_q_table) are in fact in linear order. The JPEG file header, which is
not generated by the hardware, but must be programatically created with the
CPU, expects the table in zigzag order. On the other hand, the hardware
doesn&#
From: Jonas Karlman
[ Upstream commit fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f ]
media_device_cleanup() and v4l2_m2m_unregister_media_controller() were
missing in the probe error path.
While at it, re-order calls in the remove path to unregister/cleanup
things in the reverse order they were
From: Jonas Karlman
[ Upstream commit fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f ]
media_device_cleanup() and v4l2_m2m_unregister_media_controller() were
missing in the probe error path.
While at it, re-order calls in the remove path to unregister/cleanup
things in the reverse order they were
;
> > for (...) {
> > ...
> > if (!expr)
> > continue;
> > ...
> > }
> >
> > in order to reduce indentation of conditional block. Fixed
> > indentation of cases blocks at the same time.
> >
> > Signed-off-by: Je
On Wed, May 15, 2019 at 12:14:33PM +0100, Jeremy Sowden wrote:
> Changed:
>
> for (...) {
> ...
> if (expr) {
> ...
> }
> }
>
> into:
>
> for (...) {
> ...
> if (!expr)
> continue;
> ...
> }
>
Changed:
for (...) {
...
if (expr) {
...
}
}
into:
for (...) {
...
if (!expr)
continue;
...
}
in order to reduce indentation of conditional block. Fixed indentation
of cases blocks at the same time.
Signed-off-by: Jeremy Sowden
---
drivers
Changed:
for (...) {
...
if (expr) {
...
}
}
into:
for (...) {
...
if (!expr)
continue;
...
}
in order to reduce indentation of conditional block. Fixed indentation
of cases blocks at the same time.
Signed-off-by: Jeremy Sowden
---
drivers
Hi,
On Mon, 2019-04-08 at 10:18 +0200, Paul Kocialkowski wrote:
> Hi,
>
> Le dimanche 07 avril 2019 à 20:47 +0200, Jernej Skrabec a écrit :
> > Currently, MEDIA_IOC_G_TOPOLOGY ioctl on cedrus fails due to incorrect
> > initialization order. Fix that by moving video_reg
Hi,
Le dimanche 07 avril 2019 à 20:47 +0200, Jernej Skrabec a écrit :
> Currently, MEDIA_IOC_G_TOPOLOGY ioctl on cedrus fails due to incorrect
> initialization order. Fix that by moving video_register_device() before
> v4l2_m2m_register_media_controller() and while at it, fix e
Currently, MEDIA_IOC_G_TOPOLOGY ioctl on cedrus fails due to incorrect
initialization order. Fix that by moving video_register_device() before
v4l2_m2m_register_media_controller() and while at it, fix error path.
Reported-by: Jonas Karlman
Signed-off-by: Jernej Skrabec
---
drivers/staging
From: Ajay Singh
Modified packing order for join param as expected by firmware.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/host_interface.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000
prepare_vdi_in_buffers() was setting up the dma pointers as if the
VDIC is always programmed to receive the fields in bottom-top order,
i.e. as if ipu_vdi_set_field_order() only programs BT order in the VDIC.
But that's not true, ipu_vdi_set_field_order() is working correctly.
S
prepare_vdi_in_buffers() was setting up the dma pointers as if the
VDIC is always programmed to receive the fields in bottom-top order,
i.e. as if ipu_vdi_set_field_order() only programs BT order in the VDIC.
But that's not true, ipu_vdi_set_field_order() is working correctly.
S
prepare_vdi_in_buffers() was setting up the dma pointers as if the
VDIC is always programmed to receive the fields in bottom-top order,
i.e. as if ipu_vdi_set_field_order() only programs BT order in the VDIC.
But that's not true, ipu_vdi_set_field_order() is working correctly.
S
Change the order of array declarations in rtw_mlme_ext.c to improve
readability.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging
On Thu, Oct 11, 2018 at 6:05 PM Vlastimil Babka wrote:
>
> On 10/10/18 6:56 PM, Arun KS wrote:
> > On 2018-10-10 21:00, Vlastimil Babka wrote:
> >> On 10/5/18 10:10 AM, Arun KS wrote:
> >>> When free pages are done with higher order, time spend on
> >>&g
On 2018-11-06 03:14, Andrew Morton wrote:
On Mon, 05 Nov 2018 15:12:27 +0530 Arun KS
wrote:
On 2018-10-22 16:03, Arun KS wrote:
> On 2018-10-19 13:37, Michal Hocko wrote:
>> On Thu 18-10-18 19:18:25, Andrew Morton wrote:
>> [...]
>>> So this patch needs more work, yes?
>>
>> Yes, I've talked
On Mon, 05 Nov 2018 15:12:27 +0530 Arun KS wrote:
> On 2018-10-22 16:03, Arun KS wrote:
> > On 2018-10-19 13:37, Michal Hocko wrote:
> >> On Thu 18-10-18 19:18:25, Andrew Morton wrote:
> >> [...]
> >>> So this patch needs more work, yes?
> >>
> >> Yes, I've talked to Arun (he is offline until ne
On 2018-10-22 16:03, Arun KS wrote:
On 2018-10-19 13:37, Michal Hocko wrote:
On Thu 18-10-18 19:18:25, Andrew Morton wrote:
[...]
So this patch needs more work, yes?
Yes, I've talked to Arun (he is offline until next week) offlist and
he
will play with this some more.
Converted totalhigh_
On 2018-10-19 13:37, Michal Hocko wrote:
On Thu 18-10-18 19:18:25, Andrew Morton wrote:
[...]
So this patch needs more work, yes?
Yes, I've talked to Arun (he is offline until next week) offlist and he
will play with this some more.
Converted totalhigh_pages, totalram_pages and zone->managed
On Thu 18-10-18 19:18:25, Andrew Morton wrote:
[...]
> So this patch needs more work, yes?
Yes, I've talked to Arun (he is offline until next week) offlist and he
will play with this some more.
--
Michal Hocko
SUSE Labs
___
devel mailing list
de...@lin
; > >
> > > > > > - __online_page_increment_counters(page);
> > > > > > - __online_page_free(page);
> > > > > > + __free_pages_core(page, order);
> > > > > > + totalram_pages += (1UL << order);
> > >
prepare_vdi_in_buffers() was setting up the dma pointers as if the
VDIC is always programmed to receive the fields in bottom-top order,
i.e. as if ipu_vdi_set_field_order() only programs BT order in the VDIC.
But that's not true, ipu_vdi_set_field_order() is working correctly.
S
On Thu 11-10-18 10:07:02, Vlastimil Babka wrote:
> On 10/10/18 6:56 PM, Arun KS wrote:
> > On 2018-10-10 21:00, Vlastimil Babka wrote:
> >> On 10/5/18 10:10 AM, Arun KS wrote:
> >>> When free pages are done with higher order, time spend on
> >>> coalesci
On 10/10/18 6:56 PM, Arun KS wrote:
> On 2018-10-10 21:00, Vlastimil Babka wrote:
>> On 10/5/18 10:10 AM, Arun KS wrote:
>>> When free pages are done with higher order, time spend on
>>> coalescing pages by buddy allocator can be reduced. With
>>> section size o
On Thu 11-10-18 07:59:32, Arun KS wrote:
> On 2018-10-10 23:03, Michal Hocko wrote:
> > On Wed 10-10-18 22:26:41, Arun KS wrote:
> > > On 2018-10-10 21:00, Vlastimil Babka wrote:
> > > > On 10/5/18 10:10 AM, Arun KS wrote:
> > > > > When free pa
On 2018-10-10 23:03, Michal Hocko wrote:
On Wed 10-10-18 22:26:41, Arun KS wrote:
On 2018-10-10 21:00, Vlastimil Babka wrote:
> On 10/5/18 10:10 AM, Arun KS wrote:
> > When free pages are done with higher order, time spend on
> > coalescing pages by buddy allocator can b
On Wed 10-10-18 22:26:41, Arun KS wrote:
> On 2018-10-10 21:00, Vlastimil Babka wrote:
> > On 10/5/18 10:10 AM, Arun KS wrote:
> > > When free pages are done with higher order, time spend on
> > > coalescing pages by buddy allocator can be reduced. With
> > > se
On 2018-10-10 21:00, Vlastimil Babka wrote:
On 10/5/18 10:10 AM, Arun KS wrote:
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less
On 10/5/18 10:10 AM, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> improv
On Wed, Oct 10, 2018 at 04:21:16PM +0530, Arun KS wrote:
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index e379e85..2416136 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -690,9 +690,13 @@ static int online_pages_range(unsigned long start_pfn,
> unsigned long nr_
On 2018-10-10 13:37, Oscar Salvador wrote:
On Fri, Oct 05, 2018 at 01:40:05PM +0530, Arun KS wrote:
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement
On Fri, Oct 05, 2018 at 01:40:05PM +0530, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than
On Tue 09-10-18 15:24:13, Arun KS wrote:
> On 2018-10-09 14:59, Michal Hocko wrote:
> > On Fri 05-10-18 13:40:05, Arun KS wrote:
> > > When free pages are done with higher order, time spend on
> > > coalescing pages by buddy allocator can be reduced. With
> >
On 2018-10-09 14:59, Michal Hocko wrote:
On Fri 05-10-18 13:40:05, Arun KS wrote:
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less
On Fri 05-10-18 13:40:05, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
>
On Fri, Oct 05, 2018 at 01:40:05PM +0530, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%. Modify external
providers of
On 2018-10-04 20:21, Michal Hocko wrote:
On Wed 03-10-18 19:09:39, Arun KS wrote:
[...]
+static int online_pages_blocks(unsigned long start, unsigned long
nr_pages)
+{
+ unsigned long end = start + nr_pages;
+ int order, ret, onlined_pages = 0;
+
+ while (start <
prepare_vdi_in_buffers() was setting up the dma pointers as if the
VDIC is always programmed to receive the fields in bottom-top order,
i.e. as if ipu_vdi_set_field_order() only programs BT order in the VDIC.
But that's not true, ipu_vdi_set_field_order() is working correctly.
S
On Wed 03-10-18 19:09:39, Arun KS wrote:
[...]
> +static int online_pages_blocks(unsigned long start, unsigned long nr_pages)
> +{
> + unsigned long end = start + nr_pages;
> + int order, ret, onlined_pages = 0;
> +
> + while (start < end) {
> + ord
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%. Modify external
providers of
On 2018-09-27 12:41, Juergen Gross wrote:
On 27/09/18 08:58, Arun KS wrote:
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than
On 2018-09-27 12:39, Oscar Salvador wrote:
On Thu, Sep 27, 2018 at 12:28:50PM +0530, Arun KS wrote:
+ __free_pages_boot_core(page, order);
Hi,
I am not sure, but if we are going to use that function from the
memory-hotplug code,
we might want to rename that function to something more
On 27/09/18 08:58, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> improv
On Thu, Sep 27, 2018 at 12:28:50PM +0530, Arun KS wrote:
> + __free_pages_boot_core(page, order);
I am not sure, but if we are going to use that function from the memory-hotplug
code,
we might want to rename that function to something more generic?
The word "boot" suggests that
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%.
Modify external providers of
On 2018-09-25 23:48, Michal Hocko wrote:
On Tue 25-09-18 11:59:09, Vlastimil Babka wrote:
[...]
This seems like almost complete copy of __free_pages_boot_core(),
could
you do some code reuse instead? I think Michal Hocko also suggested
that.
Yes, please try to reuse as much code as possible
On Tue 25-09-18 11:59:09, Vlastimil Babka wrote:
[...]
> This seems like almost complete copy of __free_pages_boot_core(), could
> you do some code reuse instead? I think Michal Hocko also suggested that.
Yes, please try to reuse as much code as possible
--
Michal Hocko
SUSE Labs
___
1 - 100 of 288 matches
Mail list logo
